containers-roadmap
containers-roadmap copied to clipboard
aws
[EKS] [request]: EKS authentication rolearn wildcard support aka improved support for AWS Identity Center SSO
Tell us about your request Support basic glob wildcard rolearn matching for aws-auth configmap that controls iam role eks auth.
Which service(s) is this request for? EKS
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
Trying to avoid hardcoding lots of IAM role arns into the aws-auth configmap. It would be useful if basic glob wildcard matching worked in the rolearn field of each role mapping:
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
data:
mapRoles: |
- groups: [AcmeCorp]
rolearn: arn:aws:iam::111122223333:role/teams/*
username: AcmeCorp
Are you currently working around this issue? Individually specifying each rolearn and updating the configmap everytime these roles change:
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
data:
mapRoles: |
- groups: [AcmeCorp]
rolearn: arn:aws:iam::111122223333:role/teams/SomeTeam
username: SomeTeam
- groups: [AcmeCorp]
rolearn: arn:aws:iam::111122223333:role/teams/AnotherTeam
username: AnotherTeam
Additional context
I tried using a * on a working rolearn field and the role became unable to authenticate with the api server. EKS version (Im not sure what component handles this auth delegation, so I dont know of another relevant version to check for that):
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.1", GitCommit:"4485c6f18cee9a5d3c3b4e523bd27972b1b53892", GitTreeState:"clean", BuildDate:"2019-07-18T14:25:20Z", GoVersion:"go1.12.7", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"13+", GitVersion:"v1.13.10-eks-5ac0f1", GitCommit:"5ac0f1d9ab2c254ea2b0ce3534fd72932094c6e1", GitTreeState:"clean", BuildDate:"2019-08-20T22:39:46Z", GoVersion:"go1.11.13", Compiler:"gc", Platform:"linux/amd64"}
I'd be happy to try implementing this, but im not sure if the code for this is open sourced. If it is, maybe I could be pointed to it?
I think with AWS SSO Roles this is sorta more required, as the AWS SSO roles appear to have randomly generated characters at the end of the role ARN which makes granting access to AWS SSO Roles painful.
to clarify - path support would be really helpful for user defined roles...
there is a workaround for SSO @nxtof and @sidewinder12s -
{
rolearn = "arn:aws:iam::<account_id>:role/AWSReservedSSO_AdministratorAccess_<some_random_string>"
username = "aws-sso-admin"
groups = ["system:masters"]
}
The issue is that paths aren't supported in the arn for roles - so really you get internal wildcards for free kinda? it's the leaf role name that you list after role/ - also that random string isn't randomized all the time - its created by SSO in the an account with permission set provisioned roles. it won't change after it's provisioned... but i'm not sure about what happens if role are edited and reprovisioned - haven't tried it.
there's also a side note in the docs that's kind of a little about this: https://docs.aws.amazon.com/eks/latest/userguide/troubleshooting_iam.html#security-iam-troubleshoot-ConfigMap
doesn't really mention SSO but i've verified it working as specified above.
After a few tests, I can confirm that <some_random_string> does not change every time the SSO permission set is re-provisioned in an account (e.g. permission change). I would guess it is randomly generated if you remove and then re-add it to the account, which should be rare but is still subject to happen.
Nevertheless, wildcard support would definitely be useful
Have a similar requirement to implement and wildcard support would make things easy. I wish this to be available soon.
@leofernandezg
+1 we can't integrate with AWS SSO
In fact you can, but not smoothly, by declaring the IAM role (without the sso path) : https://github.com/aws/containers-roadmap/issues/474#issuecomment-721475031
The nClouds team suggested to map aws sso role directly and there is catch we need to remove /aws.sso/ like string from sso role arn that way it will work.
@underrun - To elaborate a bit on your point, if your SSO workflow is to allow access for a single AWS account, you are complete correct. And in fact, you can even programmatically access the SSO role through terraform with the following code:
data "aws_iam_roles" "admin_sso_role" {
path_prefix = "/aws-reserved/sso.amazonaws.com/"
name_regex = "AWSReservedSSO_AdministratorAccess_.+"
}
And in your Terraform output:
output "admin_sso_role_arn" {
value = [
for parts in [for arn in data.aws_iam_roles.admin_sso_role.arns : split("/", arn)] :
format("%s/%s", parts[0], element(parts, length(parts) - 1))
][0]
}
That will give you an output value for admin_sso_role_arn of something like: arn:aws:iam::<YOUR_AWS_ACCOUNT_ID>:role/AWSReservedSSO_AdministratorAccess_<YOUR_SPECIFIC_RANDOM_STRING>
However, if you are using SSO from a central account, where the user then assumes a role in an associated account, then this breaks down. That is because the aws sts get-caller-identity of the user actually has a role ARN in the form of:
arn:aws:sts::<YOUR_AWS_ACCOUNT_ID>:assumed-role/AWSReservedSSO_AdministratorAccess_<A_DIFFERENT_RANDOM_STRING>.
That last part is brutal for our workflow - we cannot figure out a way to programmatically figure out those assume role ARNs, which is why wildcard support would be incredible for us.
That's a very long-winded way of saying "+1 for this ticket", but I hope that the Terraform code is of value to someone.
However, if you are using SSO from a central account, where the user then assumes a role in an associated account, then this breaks down. That is because the
aws sts get-caller-identityof the user actually has a role ARN in the form of:arn:aws:sts::<YOUR_AWS_ACCOUNT_ID>:assumed-role/AWSReservedSSO_AdministratorAccess_<A_DIFFERENT_RANDOM_STRING>.That last part is brutal for our workflow - we cannot figure out a way to programmatically figure out those assume role ARNs, which is why wildcard support would be incredible for us.
Same here. The dynamically generated role names are annoying.
@tachang - I should actually amend my commentl; in my case my Terraform code was wrong, and I was using the SSO role from the parent organization account instead of for the account that the user was "assuming" into. So I was actually able to solve my particular use case dynamically.
I still think that the functionality described in this thread has utility though!
+1 for this feature, which will make it useful for kubectl access with aws sso creds.
This would be super useful feature especially where there are multiple EKS Clusters and AWS Accounts relying on AWS SSO for authenticating users into the Cluster.
Any development in this issue? The ability to some sort of a wildcard for allowing role access to EKS would be extremely useful for companies relying exclusively in AWS SSO for managing clusters (it has become a management nightmare to keep up with SSO and IAM).
We are currently in the design phase for a AWS native integration solution between EKS and AWS Identity Center (Formerly named AWS SSO). Any feedback or requests can be posted here.
We are currently in the design phase for a AWS native integration solution between EKS and AWS Identity Center (Formerly named AWS SSO). Any feedback or requests can be posted here.
this issue would still apply to workloads that need automated access to the kubernetes API and that don't use SSO. this is a common pattern and would also be made easier if we could use wildcards for mapping IAM roles to kubernetes groups.
or will the solution being designed for integrating EKS and AWS Identity Center take into account giving access to EKS clusters to automated services via IAM roles?
take into account giving access to EKS clusters to automated services via IAM roles?
No, this would be Identity Center specific. Can you expand on your use case?
We automate deploying our software programmatically. Humans don't log into kubernetes (normally) to deploy workloads to kubernetes, instead remote processes use the kubernetes api to create and manage resources in eks.
We have multiple accounts and multiple services that could be used to manage workloads in kubernetes clusters. Currently the aws auth config map requires mapping each role that should have access by arn, but it would be nice to have more flexibility such that we could map a set of roles to a kubernetes user/group without having to enumerate each role.
There are workarounds, but they involve creating and managing assume role policies that essentially equate to kubernetes groups in iam rather than managing permissions closer to the resource via the config map.
@jku8 Is there any issue/PR or something else that would allow to track the progress of mentioned feature?
