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

fix: Adding support for the default namespace service account to access AWS Secret Manager #338

Closed
wants to merge 1 commit into from

Conversation

vilakshan2996
Copy link
Contributor

@vilakshan2996 vilakshan2996 commented Jan 1, 2024

What does this PR do?

we could modify the namespace of the oidc_providers service account to a custom namespace that the user can specify when using external_secrets. This way, the SecretStore can utilize that service account to access AWS Secret Manager.

Motivation

More

  • ✔️ ] Yes, I have tested the PR using my local account setup (Provide any test evidence report under Additional Notes)
  • ✔️] Yes, I ran pre-commit run -a with this PR

For Moderators

  • E2E Test successfully complete before merge?

@vilakshan2996 vilakshan2996 requested a review from a team as a code owner January 1, 2024 08:39
@vilakshan2996 vilakshan2996 changed the title Adding support for the default namespace service account to access AW… feat: Adding support for the default namespace service account to access AW… Jan 1, 2024
@vilakshan2996 vilakshan2996 changed the title feat: Adding support for the default namespace service account to access AW… fix: Adding support for the default namespace service account to access AWS Secret Manager Jan 1, 2024
@vilakshan2996 vilakshan2996 changed the title fix: Adding support for the default namespace service account to access AWS Secret Manager fix: Adding support for the default namespace service account to access AWS Secret Manager Jan 1, 2024
@rodrigobersa rodrigobersa self-assigned this Jan 10, 2024
@rodrigobersa
Copy link
Contributor

Hi @vilakshan2996.

Sorry to be repetitive here, but still not clear what are you trying to achieve. What's the issue that you are facing and what is the goal?

  • Use the external-secrets SA in another Pod.
  • Have the application to access a secret-store in a different namespace.

The addon "package" is built like this for a reason and uncouple it's resources or dependencies may generate future issues, that's why the Chart structure deploys everything together.

@csantanapr
Copy link
Contributor

By default values for the external-secret addon namespace is external-secrets and service account name external-secrets-sa if you want the addon to be deploy to a different namespace and/or service account name this is already supported with the variables:

var.external_secrets.service_account_name 
var.external_secrets.namespace 

@vilakshan2996
Copy link
Contributor Author

@rodrigobersa , Yes, the second scenario. How can we accomplish this? The application, deployed in the default namespace, needs to access the secret store located in the external-secret namespace.

@bryantbiggs
Copy link
Contributor

bryantbiggs commented Jan 19, 2024

Please start with a reproduction - I still didn't see a response on whether or not this is what you are trying to achieve:

module "eks_blueprints_addons" {
 ...

  enable_external_secrets = true
  external_secrets = {
    create_namespace = false
    namespace        = "default"
  }
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Adding support for the default namespace service account to access AWS Secret Manager in external-secrets.
4 participants