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

[vilakshan2996]

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]

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]

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]

Hey @vilakshan2996.

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

[vilakshan2996]

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]

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]

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]

Ok, and the following doesn't work?

module "eks_blueprints_addons" {
 ...

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

[vilakshan2996]

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]

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