Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow aws.* configuration inside remoteWrite #928

Open
5nafu opened this issue Apr 18, 2024 · 3 comments
Open

Allow aws.* configuration inside remoteWrite #928

5nafu opened this issue Apr 18, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@5nafu
Copy link

5nafu commented Apr 18, 2024

As a user of the operator
I would like to configure IAM based authentication inside my remoteWrite configuration
so that I don't need to (ab-)use extraArgs to use it.

The vmagent supports using IAM authentication by setting (for example) -remoteWrite.aws.roleARN et.al but the operator does not accept it as parameter yet. While it would be possible to use extraArgs to set these parameters, if used together with (for example) inlineUrlRelabelConfig one would need to generate a configmap outside of the general operator (helm) configuration and attach it to the agent. It would be better to have everything in one place.

@Haleygo
Copy link
Contributor

Haleygo commented Apr 25, 2024

Hello @5nafu .

It would be better to have everything in one place.

What do you mean by "have everything in one place"? Do you have any perferred proposal?

@5nafu
Copy link
Author

5nafu commented Apr 25, 2024

Hi @Haleygo,

Currently, if you have one or multiple remote-writes with at lease one IAM auth, your vmagent object might look like (only the relevant parts):

remoteWrite:
  - url: http://vmsingle-victoria-stack.victoria.svc:8429/api/v1/write
  - url: https://vmingest.basic.auth.url/api/v1/write
    basicAuth:
      password:
        key: password
        name: victoria-credentials
      username:
        key: username
        name: victoria-credentials
    inlineUrlRelabelConfig:
    - action: labeldrop
      regex: source_.*|destination_service_.*|destination_can.*|destination_principal
    # ... 
  - url: https://victoria.i.am.auth.url/insert/123/prometheus/api/v1/write
    inlineUrlRelabelConfig:
    - action: drop
      regex: ^kube_.*;kubecost-cost-analyzer$
      source_labels:
      - __name__
      - job
    # ...
extraArgs:
    # ...
    remoteWrite.aws.region: ',,eu-central-1'
    remoteWrite.aws.roleARN: ',,arn:aws:iam::AccountID:role/Role'
    remoteWrite.aws.service: ',,execute-api'
    remoteWrite.aws.useSigv4: false,false,true

Notice the need to add the appropriate amount of comma (and boolean values) for each remote write. It is even worse when using the helm chart, as there will be an additional "local" write that the user does not configure.

It would be better for the user if one could use a configuration similar to the basicAuth like:

remoteWrite:
  - url: http://vmsingle-victoria-stack.victoria.svc:8429/api/v1/write
  - url: https://vmingest.basic.auth.url/api/v1/write
    basicAuth:
      password:
        key: password
        name: victoria-credentials
      username:
        key: username
        name: victoria-credentials
    inlineUrlRelabelConfig:
    - action: labeldrop
      regex: source_.*|destination_service_.*|destination_can.*|destination_principal
    # ... 
  - url: https://victoria.i.am.auth.url/insert/123/prometheus/api/v1/write
    aws:
      region: 'eu-central-1'
      roleARN: 'arn:aws:iam::AccountID:role/Role'
      service: 'execute-api'
      useSigv4: true
    inlineUrlRelabelConfig:
    - action: drop
      regex: ^kube_.*;kubecost-cost-analyzer$
      source_labels:
      - __name__
      - job
    # ...

@f41gh7
Copy link
Collaborator

f41gh7 commented Jul 30, 2024

I agree, your example with separate aws spec looks better.
I think we should add more configuration params to the remoteWrite defintion. It makes configuration easy to understand without extraArgs comma-madness syntax.

@f41gh7 f41gh7 added the enhancement New feature or request label Sep 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants