Support to have IAM user Assume a Role when retrieving secret data about kubernetes-external-secrets HOT 23 CLOSED

When will this feature be released? The master branch seems to mislead unassuming users (like myself and my team) into thinking this is released, but that seems to not be the case. My team and I put in the work to prep all of our accounts with the external-secrets role and to start rolling this out and all that's missing is deploying this new release to our clusters.

Also, as a side question, do you think the state of the master branch can be released as is or are there any blocking issues that make this feature non-production ready?

from kubernetes-external-secrets.

@moolen @antoniotamer we just released a new version which should include #144

from kubernetes-external-secrets.

Is this issue resolved with the latest release? Good to close?

from kubernetes-external-secrets.

Is this issue resolved with the latest release? Good to close?

I think this is good to close. We can open follow up tickets should we run into trouble. Thanks!

from kubernetes-external-secrets.

@GeoffMillerAZ this is a really good write-up of a feature-request! If no one else is working on this i will pick it up.

from kubernetes-external-secrets.

As an extension to your proposal i would like to suggest the following to restrict access to Roles per Namespace:

RN a k8s-client can create a ExternalSecret and use any role for any account. E.g. Assume this: We have Team A in namespace team-a and Team B in team-b. Now Team A could access the SSM/SM secrets of Team B. To fix this i would like to restrict the to-be-assumed-roles an a per-namespace basis.The following example is implemented by kiam:

kind: Namespace
metadata:
  name: iam-example
  annotations:
    # this annotation restricts access to certain accounts/roles
    iam.amazonaws.com/permitted: arn:aws:iam::123456789012:*

This would allow ExternalSecrets in the namespace iam-example to only assume roles matching the regex arn:aws:iam::123456789012:*.

@GeoffMillerAZ do you have input about this?

from kubernetes-external-secrets.

With this policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam::TeamA:role/someRole", # mapped to namespace team-a
                "arn:aws:iam::TeamB:role/someRole", # ns: team-b
                "arn:aws:iam::TeamC:role/someOtherRole", # ns: team-c
            ],
            "Effect": "Allow"
        }
    ]
}

yes, the controller itself has limited access to the specified accounts. However k8s users can use all of the roles to retrieve the secrets.

Developers of TeamA can pull in secrets from TeamC by creating a ExternalSecret that uses the role arn:aws:iam::TeamC:role/someOtherRole.

In my use-case i do not want to trust developers which create the ExternalSecret resource. They should have only access to their secrets in their account from their namespace.

To restrict the access i need a way to limit the number of assumable roles per namespace (see example implementation for details)

from kubernetes-external-secrets.

@mo-saeed this feature is part of #144. Feel free to build & test it 😃

from kubernetes-external-secrets.

@mo-saeed Thanks!
There should be no need to change anything on the packaging side. It's just about the ExternalSecrets.

from kubernetes-external-secrets.

Thanks a lot @moolen for implementing this, I will wait until it's merged and will test it. Does this require any changes on the helm chart ?

I had to extend the ClusterRole to allow reading of namespaces. See pull request #177.

from kubernetes-external-secrets.

@keweilu do you have any idea about the release schedule? Do you need any help?

@antoniotamer you should be aware of #174 (IMHO not a blocker, but a nice to have for the next cycle)

from kubernetes-external-secrets.

For the record: There are some RBAC things missing. This is already being addressed by #177

from kubernetes-external-secrets.

you could even extend this concept into:

apiVersion: 'kubernetes-client.io/v1'
kind: ExternalSecret
metadata:
  name: hello-service
secretDescriptor:
  data:
    - key: hello-service/credentials
      name: password
      property: password
      backendType: secretsManager
      roleArn: arn:aws:iam::123456789012:role/somerole
    - key: hello-service/credentials
      name: username
      property: username
      backendType: systemManager
      roleArn: arn:aws:iam::210987654321:role/somerole

This would allow you to mix and match backends to combine them into a single secret. The best and most flexible idea seems to have these keys at the top layer and on each secret. If specified at the top, that is what is used for each unless overridden downstream.

from kubernetes-external-secrets.

I think you can just say that the IAM user/role that the external secrets controller will be using should be responsible for controlling which roles it can assume along with the trust relationship on the target IAM role. So you could put this role on the IAM user/role external secrets controller is using:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam::123teamAAccount321:role/someRole",
                "arn:aws:iam::123teamCAccount321:role/someRole",
                "arn:aws:iam::123teamDAccount321:role/someOtherRole",
            ],
            "Effect": "Allow"
        }
    ]
}

This would then let it assume the roles-account combos listed so long as those roles trust the IAM account where this is defined. This should provide sufficient control and is required anyway.

But this does bring up a potential issue of maybe also benefiting from defining the IAM user/role that each external secret is going to use to assume the specified role. That way you can fully define the permissions needed on each external secret. You could also apply this on each actual data point that gets pulled in and just inherit from the main external secret body if not specified on each data pull.

apiVersion: 'kubernetes-client.io/v1'
kind: ExternalSecret
metadata:
  name: hello-service
secretDescriptor:
  backendType: secretsManager
  backendConfig:
    authType: user
    userSecretRef: someSecretName
    roleArn:  arn:aws:iam::123456789012:role/somerole
  data:
    - key: hello-service/credentials
      name: password
      property: password
      backendType: secretsManager
      backendConfig:
        authType: role
        roleArn: arn:aws:iam::666666789012:role/somerole
    - key: hello-service/credentials
      name: username
      property: username

where backendConfig specifies what authType is to be used. user for iam user and role for the iam role if running on an EC2 with an instance profile or using KIAM.

An authType of user will expect to find a userSecretRef that is the name of a secret to tell it how to find the aws credentials with data keys aws_access_key_id and aws_secret_access_key. It will then log into this to pull the secrets. But if roleArn is specified in the backendConfig it will first assume that role before trying to read that secret.

An authType of role will expect use the iam role of the pod/node (depending on setup of the cluster) to pull the secret. If it sees a specified roleArn it will use the iam role of the pod/node to instead assume the specified roleArn and then read the secret.

A backendConfig with authType of user would support the following usage:

backendConfig:
        authType: <user> (required)
        userSecretRef: <name of secret to get aws access keys> (required)
        region: (optional and defaults to the default region of the aws config)
        roleArn: <valid iam role arn to assume> (optional)

A backendConfig with authType of role would support the following usage:

backendConfig:
        authType: <role> (required)
        region: (optional and defaults to the default region of the aws config)
        roleArn: <valid iam role arn to assume> (optional)

If backendConfig is not specified authType: role would be defaulted to. backendConfig can be specified at the secretDescriptor level or on an instance in the data level. The backendConfig at the secretDescriptor level should be used if an instance in the data level does not specify any config.

I know it's a bit of a change from my first suggestion but this would give the most amount of control on a per-secret basis. And I think whoever sets up these users and roles should be where the restrictions occur.

from kubernetes-external-secrets.

@moolen I see. Yea I think your solution of supporting annotations to limit this as well is a great idea.

from kubernetes-external-secrets.

@moolen @GeoffMillerAZ +1 for the need of this

kind: Namespace
metadata:
  name: iam-example
  annotations:
    # this annotation restricts access to certain accounts/roles
    iam.amazonaws.com/permitted: arn:aws:iam::123456789012:*

I hope this can be implemented soon....

from kubernetes-external-secrets.

Thanks a lot @moolen for implementing this, I will wait until it's merged and will test it. Does this require any changes on the helm chart ?

from kubernetes-external-secrets.

Thanks @moolen. Is kiam in fact needed at all for role assumption to work? We don’t have that installed in our cluster and the docs don’t really make that distinction.

from kubernetes-external-secrets.

🎉 thanks @keweilu ❤️
@antoniotamer kiam itself not needed. But external-secrets needs credentials to be able to assume roles (via environment variables, EC2 instance metadata, etc..)

edit
i think we can close this issue then, right?

from kubernetes-external-secrets.

This is so appreciated!! Thank you! 💯

from kubernetes-external-secrets.

I’ll need to test it tomorrow. We’re excited about this!

from kubernetes-external-secrets.

For the record: There are some RBAC things missing. This is already being addressed by #177

Thanks for pointing that out! I was aware of that PR being open still. We can add the missing rbac permission with kustomize on our side while we wait for another release.

from kubernetes-external-secrets.

This is so far working for us, with our preliminary testing. We're rolling this to some of our deployments and so far so good

from kubernetes-external-secrets.