Add impersonate (e.g. `--as`) options

[poehlerflorian]

Describe the problem/challenge you have
kubectl allows specifying --as, --as-group, or --as-uid to impersonate a different user. I would expect kapp to work the same way. This allows e.g. to use a user with read-only access by default and specify --as=<user> to apply changes to the cluster. This can prevent accidental cluster changes by forcing the user to explicitly specify the user with write-access.

Describe the solution you'd like
I want to be able to pass --as, --as-group, or --as-uid options to any kapp command that interacts with the cluster. These options should be passed through to kubectl or added as HTTP header to the API call.

Anything else you would like to add:

• https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation
• https://kubernetes.io/docs/reference/kubectl/generated/kubectl/#options

---

Vote on this request

This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.

👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"

We are also happy to receive and review Pull Requests if you want to help working on this issue.

[joaopapereira]

To me, this sounds like an interesting feature @100mik @praveenrewar what do yll think?

[praveenrewar]

Sounds interesting, I think it makes sense to have the same impersonate behaviour in kapp. I do have some thoughts regarding the accidental cluster changes though:

This can prevent accidental cluster changes by forcing the user to explicitly specify the user with write-access.

I think that in kapp accidental changes are prevented by the initial summary/diff that kapp provides based on which we can decide if we want to proceed with the changes or not.

[poehlerflorian]

This can prevent accidental cluster changes by forcing the user to explicitly specify the user with write-access.

I think that in kapp accidental changes are prevented by the initial summary/diff that kapp provides based on which we can decide if we want to proceed with the changes or not.

That should be sufficient when using kapp directly. We are using it as part of a self written tool though and calling it with --yes. The tool currently elevates the permissions when necessary by creating a temp kubeconfig with the impersonate option set and setting the KAPP_KUBECONFIG var. This works but is kind of a hacky workaround. Simply providing the user with a flag (e.g. --as) like for kubectl, k9s etc. is more elegant in my opinion.

[github-actions]

This issue is being marked as stale due to a long period of inactivity and will be closed in 5 days if there is no response.

[poehlerflorian]

Simple comment to prevent issue from being closed, since I still think this would be a nice feature.