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

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

Closed
vilakshan2996 opened this issue Jan 1, 2024 · 9 comments

Comments

@vilakshan2996
Copy link
Contributor

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

What is the outcome that you are trying to reach?

Currently, the service account for external-secrets is created in the external-secrets namespace when using the Helm chart. However, my applications are in the default namespace, and I want the external-secrets service account to be in the default namespace as well. This allows me to update the Kubernetes Secret in the default namespace, and subsequently, utilize those updated values in my applications. If the external-secrets service account is in a different namespace, I cannot use the secret store in the default namespace to fetch updates from AWS Secret Manager. Please correct me if I am mistaken.

Describe the solution you would like

So, it would be better if 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.

@rodrigobersa
Copy link
Contributor

Hey @vilakshan2996, thanks for raising this.

You mean to have the SA deployed in a namespace different from the Helm Chart? If yes, have you tested this or have any examples of this working in your environment? Asking because IRSA may not have permissions if deployed like this.

@vilakshan2996
Copy link
Contributor Author

In my current setup, I've created a new Service Account (SA) named "external-secrets-sa" in the default namespace and annotated it to associate with an IAM role. The Terraform code snippet for this looks like:

resource "kubernetes_service_account" "external_secrets" {
  metadata {
    name = "external-secrets-sa"
    annotations = {
      "eks.amazonaws.com/role-arn" = "arn:aws:iam::xxxxxxxxxxxxxxxx:role/${local.name}-external-secrets"
    }
  }
}

as I used

external_secrets = {
    service_account_namespace = "default"
    role_name = "${local.name}-external-secrets"
    role_name_use_prefix = false
  }

I can use the known value for the 'eks.amazonaws.com/role-arn.' If not, is there any way to retrieve the value from the Helm chart regarding the created IAM role ARN so that I can use it directly in the annotation?

@rodrigobersa
Copy link
Contributor

Hey @vilakshan2996.

So you're creating the SA outside the addons module? And external-secrets could successfully access the AWS Resources?

@vilakshan2996
Copy link
Contributor Author

vilakshan2996 commented Jan 13, 2024

Yes , But 'eks_blueprints_addons,' which internally includes another module named 'external_secrets.' Inside 'external_secrets,' there is a resource that creates an IAM role. How can I access the ARN of this IAM role in my main Terraform configuration file? if that possible, we can make it even more simple.

@bryantbiggs
Copy link
Contributor

What is the end goal you are trying to achieve? In theory, this module provides everything needed with options to customize but its not clear what your overall end goal or motivation is

@vilakshan2996
Copy link
Contributor Author

The service account in the default namespace utilizes an OIDC identity provider for connecting to AWS Secret Manager. Currently, only the service account in the 'external-secret' namespace is permitted to access the Secret Manager.

Final goal is to access secret for my application on default namespace.

@bryantbiggs
Copy link
Contributor

Ok, and the following doesn't work?

module "eks_blueprints_addons" {
 ...

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

@vilakshan2996
Copy link
Contributor Author

In our scenario, we deploy our primary components (applications) within the default namespace, utilizing Fargate. Meanwhile, additional addon applications, such as external-secret , coredns in others namespaces, run on an EKS managed node group. External-secret generates three pods, and the cost associated with running it on Fargate is higher compared to hosting it on an EKS managed EC2 instance.

@bryantbiggs
Copy link
Contributor

I'm sorry but I don't follow how that is related. Did you try plugging the above configuration snippet into your configuration?

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