-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
[aws-eks] OpenID Connect provider association with AWS account #5388
Comments
Currently I'm investigating the possibilities to implement this feature and my suggestion is to implement this in the When the cluster is active we can obtain the oidc issuer url from To enable this behaviour we can either add a property to the ClusterProps like Think I'll have an initial PR ready early next week. |
Sounds great. Would love this contribution! |
Until this PR is closed off... Native CloudFormation support still doesn't exist, but if you would like to create an OIDC provider using pure YAML / JSON (using inlined lambdas) we've written that up here: https://bambooengineering.io/configuring-eks-for-iam-oidc-using-cloudformation/ The full demo with templates is in this repo. |
Thank you for this direction I’ll definitely take a look. Was planning to continue this weekend and will explore this options. |
PR #6062 has now a working implementation to support this. It add a new ServiceAccount construct which you can use to add IAM policies. Using the service account with you Pod will result in a least privilege access policies to AWS resources. Working example: const account = new ServiceAccount(this, 'ALBIngressController', {
cluster: cluster,
name: 'alb-ingress-controller',
namespace: 'kube-system'
});
account.addToPolicy(
new PolicyStatement({
resources: ['*'],
actions: [
"acm:DescribeCertificate",
"acm:ListCertificates",
"acm:GetCertificate",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CreateSecurityGroup",
"ec2:CreateTags",
"ec2:DeleteTags",
"ec2:DeleteSecurityGroup",
"ec2:DescribeAccountAttributes",
"ec2:DescribeAddresses",
"ec2:DescribeInstances",
"ec2:DescribeInstanceStatus",
"ec2:DescribeInternetGateways",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeTags",
"ec2:DescribeVpcs",
"ec2:ModifyInstanceAttribute",
"ec2:ModifyNetworkInterfaceAttribute",
"ec2:RevokeSecurityGroupIngress",
"elasticloadbalancing:AddListenerCertificates",
"elasticloadbalancing:AddTags",
"elasticloadbalancing:CreateListener",
"elasticloadbalancing:CreateLoadBalancer",
"elasticloadbalancing:CreateRule",
"elasticloadbalancing:CreateTargetGroup",
"elasticloadbalancing:DeleteListener",
"elasticloadbalancing:DeleteLoadBalancer",
"elasticloadbalancing:DeleteRule",
"elasticloadbalancing:DeleteTargetGroup",
"elasticloadbalancing:DeregisterTargets",
"elasticloadbalancing:DescribeListenerCertificates",
"elasticloadbalancing:DescribeListeners",
"elasticloadbalancing:DescribeLoadBalancers",
"elasticloadbalancing:DescribeLoadBalancerAttributes",
"elasticloadbalancing:DescribeRules",
"elasticloadbalancing:DescribeSSLPolicies",
"elasticloadbalancing:DescribeTags",
"elasticloadbalancing:DescribeTargetGroups",
"elasticloadbalancing:DescribeTargetGroupAttributes",
"elasticloadbalancing:DescribeTargetHealth",
"elasticloadbalancing:ModifyListener",
"elasticloadbalancing:ModifyLoadBalancerAttributes",
"elasticloadbalancing:ModifyRule",
"elasticloadbalancing:ModifyTargetGroup",
"elasticloadbalancing:ModifyTargetGroupAttributes",
"elasticloadbalancing:RegisterTargets",
"elasticloadbalancing:RemoveListenerCertificates",
"elasticloadbalancing:RemoveTags",
"elasticloadbalancing:SetIpAddressType",
"elasticloadbalancing:SetSecurityGroups",
"elasticloadbalancing:SetSubnets",
"elasticloadbalancing:SetWebACL",
"iam:CreateServiceLinkedRole",
"iam:GetServerCertificate",
"iam:ListServerCertificates",
"waf:GetWebACL",
"waf-regional:GetWebACLForResource",
"waf-regional:GetWebACL",
"waf-regional:AssociateWebACL",
"waf-regional:DisassociateWebACL",
"tag:GetResources",
"tag:TagResources"
]
}));
cluster.addResource('ALBIngressControllerRBAC',
{
"apiVersion": "rbac.authorization.k8s.io/v1",
"kind": "ClusterRole",
"metadata": {
"labels": {
"app.kubernetes.io/name": account.serviceAccountName
},
"name": account.serviceAccountName
},
"rules": [
{
"apiGroups": [
"",
"extensions"
],
"resources": [
"configmaps",
"endpoints",
"events",
"ingresses",
"ingresses/status",
"services"
],
"verbs": [
"create",
"get",
"list",
"update",
"watch",
"patch"
]
},
{
"apiGroups": [
"",
"extensions"
],
"resources": [
"nodes",
"pods",
"secrets",
"services",
"namespaces"
],
"verbs": [
"get",
"list",
"watch"
]
}
]
},
{
"apiVersion": "rbac.authorization.k8s.io/v1",
"kind": "ClusterRoleBinding",
"metadata": {
"labels": {
"app.kubernetes.io/name": account.serviceAccountName
},
"name": account.serviceAccountName
},
"roleRef": {
"apiGroup": "rbac.authorization.k8s.io",
"kind": "ClusterRole",
"name": account.serviceAccountName
},
"subjects": [
{
"kind": "ServiceAccount",
"name": account.serviceAccountName,
"namespace": "kube-system"
}
]
});
cluster.addChart('ALBIngressController', {
chart: 'aws-alb-ingress-controller',
repository: 'http://storage.googleapis.com/kubernetes-charts-incubator',
namespace: 'kube-system',
values: {
autoDiscoverAwsRegion: true,
autoDiscoverAwsVpcID: true,
clusterName: cluster.clusterName,
rbac: {
create: false,
serviceAccountName: account.serviceAccountName
}
}
}); |
## Commit Message feat(eks): IAM roles for service accounts (#6062) Adds support for IAM roles for service account which allows pods the assume IAM roles. NOTE: currently there are no condition set on the IAM Role which results that there are no restrictions on other pods to assume the role. This will be fixed in a subsequent PR. See README for details. Fixes #5388 Fixes #3949 ## End of Commit Message - [x] Enable OpenID Connect Provider - [x] Service Account construct - [ ] Role constraints - [x] Add `cluster.addServiceAccount` convenience method - [x] Integration Tests - [x] Unit Tests - [x] Update README.md ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license* <!-- Please read the contribution guidelines and follow the pull-request checklist: https://github.com/aws/aws-cdk/blob/master/CONTRIBUTING.md -->
## Commit Message feat(eks): IAM roles for service accounts (aws#6062) Adds support for IAM roles for service account which allows pods the assume IAM roles. NOTE: currently there are no condition set on the IAM Role which results that there are no restrictions on other pods to assume the role. This will be fixed in a subsequent PR. See README for details. Fixes aws#5388 Fixes aws#3949 ## End of Commit Message - [x] Enable OpenID Connect Provider - [x] Service Account construct - [ ] Role constraints - [x] Add `cluster.addServiceAccount` convenience method - [x] Integration Tests - [x] Unit Tests - [x] Update README.md ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license* <!-- Please read the contribution guidelines and follow the pull-request checklist: https://github.com/aws/aws-cdk/blob/master/CONTRIBUTING.md -->
Freature refers to fine-grained IAM roles for service accounts. In this approach, pods are pods first class citizens in IAM. To make the feature work, OpenID provider which comes with EKS needs to be associated with AWS account. More one here: https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html
eksctl does that in one command. Unfortunatelly there is no native cloudformation support so it cannot be set up automatically.
The goal would be to add a parameter to EKS cluster constructor, which would let programmer decide whether to associate the EKS OpenID with AWS IAM.
Use Case
I'd like to use AWS native support for IAM roles for pods rather than 3rd party solutions like role-credential interceptors (kube2iam for instance).
Proposed Solution
kubectl_enabled flag (introduced in CDK 1.4, if I recall correctly), changes the approach to the way how EKS is provisioned. You could follow the same route and perform custom logic after cluster is deployed. The logic would need to perform following steps (more about this here: https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html):
This is a 🚀 Feature Request
The text was updated successfully, but these errors were encountered: