-
Notifications
You must be signed in to change notification settings - Fork 323
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
[EKS] [bugfix]: Federated roles containing paths don't work properly with EKS #573
Comments
You need to map the role without the path in the |
I can confirm that this works for non-federated roles as well. |
This is relevant to #474 |
Tracked in |
In case anyone wanders into this... After hours of thinking, screaming, contemplating... I had to do this in CDK world that adds a duplicate role mapping for the node role without the path: ....
....
node_role = iam.Role(
self,
f"EksBootstrapNodeRole",
assumed_by=iam.ServicePrincipal("ec2.amazonaws.com"),
description=f"Node role for EKS cluster: {cluster_name}",
path="/ci-runners/",
managed_policies=[
iam.ManagedPolicy.from_aws_managed_policy_name(
"AmazonEKSWorkerNodePolicy"
),
iam.ManagedPolicy.from_aws_managed_policy_name(
"AmazonEC2ContainerRegistryReadOnly"
),
iam.ManagedPolicy.from_aws_managed_policy_name(
"AmazonSSMManagedInstanceCore"
),
],
)
# aws-iam-authenticator removes path from the assumed-role causing Kubernetes authenticator to fail server-side.
role_arn_for_aws_auth = Fn.join(
"",
[
"arn:",
Aws.PARTITION,
":iam::",
Aws.ACCOUNT_ID,
":role/",
node_role.role_name,
],
)
role_for_aws_auth = iam.Role.from_role_arn(
self, "EksBootstrapNodeRoleForAwsAuth", role_arn_for_aws_auth
)
cluster.aws_auth.add_role_mapping(
role_for_aws_auth,
username="system:node:{{EC2PrivateDNSName}}",
groups=[
"system:bootstrappers",
"system:nodes",
],
)
....
.... |
Addressed with #185 |
Greetings,
I apologize if this is not the right venue for this. I have tried to post this in the forums but I was greeted with a 500 error :(
I have authentication issues while issuing kubectl commands against an EKS cluster, while assuming a role through Okta. The role ARN is
arn:aws:iam::XXXXXXXXXXXX:role/teams/tooling/dev-tooling-operator
Upon examining the authenticator logs, I noticed that IAM(?) is reporting an ARN without the path in it back to the authenticator:
Are you currently working around this issue?
I recreated my IAM roles without paths in them.
Is this really the expected behaviour or is it indeed a bug?
Regards,
Luiz
The text was updated successfully, but these errors were encountered: