-
Notifications
You must be signed in to change notification settings - Fork 174
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
Docker images with non-root account fails to read token file #8
Comments
Problem seems to be here: For |
Hey thanks for this report, we'll leave this open and resolve once Kubernetes fixes the access mode |
A pity this kind of blocks the usage of the native IAM integration until fixed. Any workable solutions until this is fixed upstream? |
Seems like this is kind-of intended. There is a workaround here: |
Adding securityContext to the yaml file resolved this issue. Updated the PR to update the AWS tutorial: |
…projected svc acct tokens Ref: aws/amazon-eks-pod-identity-webhook#8 Signed-off-by: Daniel Herman <[email protected]>
I see a lot of people cross-referencing issues to this. For anyone else stumbling across this, can you reference the upstream issue too? (kubernetes/kubernetes#82573) That will give more signal to upstream that this is a painful issue |
due to aws/amazon-eks-pod-identity-webhook#8 Signed-off-by: Michael Hausenblas <[email protected]>
Just an update for folks here, new file permission strategy has been implemented for 1.19 in this PR: kubernetes/kubernetes#89193 Taking a look at the KEP (kubernetes/enhancements#1598), it appears that the following chain of permission checking will take place (mostly copied directly from KEP):
|
AWS pod identity creates a token with `0600` permissions and `root:root`: ``` -rw------- 1 root root 1498 Aug 13 12:47 /run/secrets/eks.amazonaws.com/serviceaccount/..2020_08_13_12_47_11.793276204/token ``` This prevents programs running inside containers using a non-root account to read the token. See [1] for details. This CR working around that by adding ``` securityContext: fsGroup: 33 ``` into the pod spec. After that the token is owned by the given group and has `0640` permissions: ``` -rw-r----- 1 root www-data 1498 Aug 13 14:20 /run/secrets/eks.amazonaws.com/serviceaccount/..2020_08_13_14_20_31.793276204/token ``` The id of the group can be changed via the `fs_group` service parameter. [1] aws/amazon-eks-pod-identity-webhook#8
AWS pod identity creates a token with `0600` permissions and `root:root`: ``` -rw------- 1 root root 1498 Aug 13 12:47 /run/secrets/eks.amazonaws.com/serviceaccount/..2020_08_13_12_47_11.793276204/token ``` This prevents programs running inside containers using a non-root account to read the token. See [1] for details. This CR working around that by adding ``` securityContext: fsGroup: 65534 ``` into the pod spec. After that the token is owned by the given group and has `0640` permissions: ``` -rw-r----- 1 root nobody 1498 Aug 13 14:20 /run/secrets/eks.amazonaws.com/serviceaccount/..2020_08_13_14_20_31.793276204/token ``` The id of the group can be changed via the `fs_group` service parameter. [1] aws/amazon-eks-pod-identity-webhook#8
@hasheddan came late to the discussion, but I'm wondering which Kubernetes version does the
solution work in? Is this solution only available in |
Might especially be useful with service account sometimes, e.g. see: aws/amazon-eks-pod-identity-webhook#8 (comment) kubernetes/kubernetes#82573
This fixed the issue for me ( unrelated to external dns ), where the container runs as user
Perhaps this page should be updated to include the extra step for EKS < 1.19 |
This is actually found in the official docs now AWS also recently posted 1.19 which fixes this |
What happened:
Tried to install External DNS to my EKS cluster with amazon-eks-pod-identity-webhook
What you expected to happen:
External DNS working with IAM credentials provided by amazon-eks-pod-identity-webhook
How to reproduce it (as minimally and precisely as possible):
Note: I confirmed amazon-eks-pod-identity-webhook is working properly when using root accounts in the pods.
Anything else we need to know?:
I've reported this issue to external dns project: kubernetes-sigs/external-dns#1185
And it seems odd that kubernetes service account volume mounted token files are with permission 0644 and the EKS tokens are with permission 0600.
EKS tokens seems to be 0600:
Kubernetes tokens seems to be 0644:
I've seen the code, and the code doesn't specify the token file permission. So the default 0644 should be used. Maybe this is a k8s upstream bug?
Environment:
aws eks describe-cluster --name <name> --query cluster.platformVersion
): "eks.1"aws eks describe-cluster --name <name> --query cluster.version
): "1.14"The text was updated successfully, but these errors were encountered: