Skip to content

kubectl debug with --as and --as-group overwrites service account #1715

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

Closed
youwalther65 opened this issue Feb 13, 2025 · 3 comments
Closed
Labels
kind/bug Categorizes issue or PR as related to a bug. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.

Comments

@youwalther65
Copy link

What happened:
I am running kubectl debug in an AWS environment and want to use the AWS IAM privileges of the kube-system/ebs-csi-controller-sa (using AWS IAM roles for service accounts). But this service account does not have K8s privileges for node objects, so I have to run with --as-group system:masters in addition. So finally I have
When running:

$ kubectl debug node/ip-<redacted>.compute.internal -it --profile=sysadmin --image=<redacted>.dkr.ecr.<redacted>.amazonaws.com/node-debug-container:1.4 --as kube-system/ebs-csi-controller-sa --as-group system:masters

which gives me a Bash prompt. But looking at the pod spec I see that it runs with serviceAccount: default and so the pod does not have the IAM privileges of kube-system/ebs-csi-controller-sa

What you expected to happen:
kubectl debug should merge --as ... --as-group .. and run debug pod with respective service account

How to reproduce it (as minimally and precisely as possible):

Run a command similar to the above in an EKS cluster with EBS CSI driver installed and using IRSA and specify for example a publicly available image like:

kubectl debug node/<redacted> -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023 --as kube-system/ebs-csi-controller-sa --as-group system:masters

Anything else we need to know?:

Environment:

  • Kubernetes client and server versions (use kubectl version): v1.32.1
  • Cloud provider or hardware configuration: AWS EKS
  • OS (e.g: cat /etc/os-release):
@youwalther65 youwalther65 added the kind/bug Categorizes issue or PR as related to a bug. label Feb 13, 2025
@k8s-ci-robot k8s-ci-robot added the needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. label Feb 13, 2025
@k8s-ci-robot
Copy link
Contributor

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

@youwalther65
Copy link
Author

Oops, I saw i sued wrong syntax for service account which needs --as=system:serviceaccount:kube-system/ebs-csi-controller-sa. Will check and try again

@youwalther65
Copy link
Author

I was on the wrong way because I had to use spec.serviceAccount directly not run --as or --as-group

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.
Projects
None yet
Development

No branches or pull requests

2 participants