Bootstrap kubernetes RBACs when running EKS auto discovery#41693
Merged
Bootstrap kubernetes RBACs when running EKS auto discovery#41693
Conversation
tigrato
force-pushed
the
tigrato/teleport-discovery-access-entry
branch
2 times, most recently
from
75605b4 to
f862008
Compare
AntonAM
reviewed
May 21, 2024
tigrato
force-pushed
the
tigrato/teleport-discovery-access-entry
branch
from
4d02431 to
4df52d9
Compare
AntonAM
approved these changes
May 23, 2024
tigrato
force-pushed
the
tigrato/teleport-discovery-access-entry
branch
from
4df52d9 to
1a56fdb
Compare
Contributor
Author
|
@gabrielcorado @smallinsky can you please take a look? |
smallinsky
reviewed
May 27, 2024
Contributor
There was a problem hiding this comment.
Do we need to call strings.TrimRight ? rstrip('=')
Suggested change
| return v1Prefix + base64.RawURLEncoding.EncodeToString([]byte(presignedURLString)), tokenExpiration, nil | |
| return v1Prefix + base64.RawURLEncoding.EncodeToString([]byte(presignedURLString)), tokenExpiration, nil |
Contributor
Author
There was a problem hiding this comment.
It's not required. = represents padding in b64 and it works anyway.
aws cli strips them but iam authenticator doesn't
Comment on lines
175
to
177
Contributor
There was a problem hiding this comment.
Can we use lazy evaluation for the fetcher.setCallerIdentity call ?
Correct me if I'm wrong but It looks that If this call will fail during setup the whole service will fail to start.
I think that we should avoid this kind of dependency where a one failing call will stop the whole discovery service. Ideally this should be done by lazy evaluation with proper error handling.
Contributor
Author
There was a problem hiding this comment.
handled in b7f08fd
in theory the GetCallerIdentity only fails if we don't have any identity associated which is already a blocker for the discovery service
smallinsky
approved these changes
May 27, 2024
This PR extends the ability of `discovery_service` to self-bootstrap the required permissions for the `kubernetes_service` to dial and forward requests to the Kubernetes API on behalf of the users. When EKS auto-discovery was initially developed, it wasn't possible to bootstrap the required permissions without having prior access to the cluster itself. Recently, AWS releases a new API to configure access to IAM identities. By default, there are just a few predifined permissions that either don't have the required permissions for `kubernetes_service` to be operational or are the equivalent of `cluster-admin` RBAC role. To bypass it, `discovery_service` temporarily escalates itself to `cluster-admin` by creating an EKS `AccessEntry` and associates the policy `arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy`. Once access is granted, it creates a Kubernetes RBAC `ClusterRole` and `ClusterRoleBinding` with the minimal required permissions for `kubernetes_service` to be operational. These permissions are binded to `teleport:kube-service:eks`. Finally, it deletes the previously created `AccessEntry` and creates another for the target ARN that Kubernetes Service uses. Fixes #39021 Signed-off-by: Tiago Silva <tiago.silva@goteleport.com>
tigrato
force-pushed
the
tigrato/teleport-discovery-access-entry
branch
from
b7f08fd to
35fb33f
Compare
tigrato
added a commit
that referenced
this pull request
May 28, 2024
* Bootstrap kubernetes RBACs when running EKS auto discovery This PR extends the ability of `discovery_service` to self-bootstrap the required permissions for the `kubernetes_service` to dial and forward requests to the Kubernetes API on behalf of the users. When EKS auto-discovery was initially developed, it wasn't possible to bootstrap the required permissions without having prior access to the cluster itself. Recently, AWS releases a new API to configure access to IAM identities. By default, there are just a few predifined permissions that either don't have the required permissions for `kubernetes_service` to be operational or are the equivalent of `cluster-admin` RBAC role. To bypass it, `discovery_service` temporarily escalates itself to `cluster-admin` by creating an EKS `AccessEntry` and associates the policy `arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy`. Once access is granted, it creates a Kubernetes RBAC `ClusterRole` and `ClusterRoleBinding` with the minimal required permissions for `kubernetes_service` to be operational. These permissions are binded to `teleport:kube-service:eks`. Finally, it deletes the previously created `AccessEntry` and creates another for the target ARN that Kubernetes Service uses. Fixes #39021 Signed-off-by: Tiago Silva <tiago.silva@goteleport.com> * handle review comments * do not exit on failed GetCallerIdentity call --------- Signed-off-by: Tiago Silva <tiago.silva@goteleport.com>
github-merge-queue Bot
pushed a commit
that referenced
this pull request
May 28, 2024
…42075) * Bootstrap kubernetes RBACs when running EKS auto discovery This PR extends the ability of `discovery_service` to self-bootstrap the required permissions for the `kubernetes_service` to dial and forward requests to the Kubernetes API on behalf of the users. When EKS auto-discovery was initially developed, it wasn't possible to bootstrap the required permissions without having prior access to the cluster itself. Recently, AWS releases a new API to configure access to IAM identities. By default, there are just a few predifined permissions that either don't have the required permissions for `kubernetes_service` to be operational or are the equivalent of `cluster-admin` RBAC role. To bypass it, `discovery_service` temporarily escalates itself to `cluster-admin` by creating an EKS `AccessEntry` and associates the policy `arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy`. Once access is granted, it creates a Kubernetes RBAC `ClusterRole` and `ClusterRoleBinding` with the minimal required permissions for `kubernetes_service` to be operational. These permissions are binded to `teleport:kube-service:eks`. Finally, it deletes the previously created `AccessEntry` and creates another for the target ARN that Kubernetes Service uses. Fixes #39021 * handle review comments * do not exit on failed GetCallerIdentity call --------- Signed-off-by: Tiago Silva <tiago.silva@goteleport.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR extends the ability of
discovery_serviceto self-bootstrap the required permissions for thekubernetes_serviceto dial and forward requests to the Kubernetes API on behalf of the users.When EKS auto-discovery was initially developed, it wasn't possible to bootstrap the required permissions without having prior access to the cluster itself. Recently, AWS releases a new API to configure access to IAM identities. By default, there are just a few predefined permissions that either don't have the required permissions for
kubernetes_serviceto be operational or are the equivalent ofcluster-adminRBAC role.To bypass it,
discovery_servicetemporarily escalates itself tocluster-adminby creating an EKSAccessEntryand associates the policyarn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy.Once access is granted, it creates a Kubernetes RBAC
ClusterRoleandClusterRoleBindingwith the minimal required permissions forkubernetes_serviceto be operational. These permissions are bonded toteleport:kube-service:eks.Finally, it deletes the previously created
AccessEntryand creates another for the target ARN that Kubernetes Service uses.Fixes #39021
Changelog: Extended Discovery Service to self-bootstrap necessary permissions for Kubernetes Service to interact with the Kubernetes API on behalf of users.