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 passing an array to credentialsConfig #425

Open
Sinjo opened this issue Mar 23, 2022 · 2 comments
Open

Allow passing an array to credentialsConfig #425

Sinjo opened this issue Mar 23, 2022 · 2 comments
Labels
kind/enhancement Categorizes issue or PR as related to an improvement. priority/low Issue that might be added to backlog or be rejected. priority/waiting Lowest priority. Possibly useful, but not yet enough support to actually get it done.

Comments

@Sinjo
Copy link

Sinjo commented Mar 23, 2022

Problem

Currently, it's not possible to configure multiple sets of credentials with credentialsConfig, as it only accepts an object, such as:

credentialsConfig:
  env: AWS_SHARED_CREDENTIALS_FILE
  path: /etc/aws/credentials
  secretName: aws-credentials

In most circumstances this isn't an issue as the vast majority of users will only have instances in a single cloud authenticating with vault.

Where it becomes a little painful is when you have instances in multiple clouds and want to authenticate them with Vault using IAM plugins. For example, if you're using both AWS and GCP IAM-based auth, Vault needs credentials for both cloud providers in order to verify the authentication requests sent by instances.

Proposed solution

Ideally, the CRD would allow an array to be provided in credentialsConfig, like this:

credentialsConfig:
  - env: AWS_SHARED_CREDENTIALS_FILE
    path: /etc/aws/credentials
    secretName: aws-credentials
  - env: GOOGLE_APPLICATION_CREDENTIALS
    path: /etc/gcp/credentials.json
    secretName: gcp-credentials

For backwards compatibility, it could still allow a single object to be passed in.

Alternatives (current workaround)

To get around this, we're currently using a mixture of volumes, volumeMounts and vaultEnvsConfig:

volumes:
  - name: gcp-credentials
    secret:
      secretName: gcp-credentials

volumeMounts:
  - name: gcp-credentials
    mountPath: /etc/gcp

  vaultEnvsConfig:
    - name: GOOGLE_APPLICATION_CREDENTIALS
      value: /etc/gcp/credentials.json

This does the job, and isn't too bad, but is slightly less convenient and was a little harder to discover.

Additional context

I realise this is only relevant for people with instances in multiple clouds, so probably not the highest priority. If you think it's a good idea I'm happy to have a go at adding it. Would appreciate a pointer towards the right place to edit and then run any codegen for the CRDs if so!

@avoidik
Copy link

avoidik commented Mar 31, 2022

unfortunately, provided workaround does not mount volumes to configurer pod, I'll try to take a look on array implementation after I finish with kvv2 check-and-set

@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR that has become stale and will be auto-closed. label Mar 24, 2024
@csatib02 csatib02 removed the lifecycle/stale Denotes an issue or PR that has become stale and will be auto-closed. label Mar 24, 2024
@ramizpolic ramizpolic transferred this issue from bank-vaults/bank-vaults Apr 5, 2024
@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR that has become stale and will be auto-closed. label Jun 9, 2024
@bank-vaults bank-vaults deleted a comment from github-actions bot Jun 9, 2024
@bank-vaults bank-vaults deleted a comment from github-actions bot Jun 11, 2024
@ramizpolic ramizpolic changed the title [Operator] Allow passing an array to credentialsConfig Allow passing an array to credentialsConfig Jun 11, 2024
@ramizpolic ramizpolic added priority/waiting Lowest priority. Possibly useful, but not yet enough support to actually get it done. kind/enhancement Categorizes issue or PR as related to an improvement. priority/low Issue that might be added to backlog or be rejected. and removed lifecycle/stale Denotes an issue or PR that has become stale and will be auto-closed. labels Jun 11, 2024
@ramizpolic
Copy link
Member

This is still low priority so we are not sure if we will actually end up working on it. If someone from the community would like to give it a go, it should be fairly simple to get started and we can provide any help needed to get it done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement Categorizes issue or PR as related to an improvement. priority/low Issue that might be added to backlog or be rejected. priority/waiting Lowest priority. Possibly useful, but not yet enough support to actually get it done.
Projects
None yet
Development

No branches or pull requests

4 participants