Add constrained impersonation blog (KEP-5284)#52916
Add constrained impersonation blog (KEP-5284)#52916benjaminapetersen wants to merge 2 commits intokubernetes:mainfrom
Conversation
k8s-ci-robot
added
area/blog
✅ Pull request preview available for checkingBuilt without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Not yet ready for review, so: |
k8s-ci-robot
changed the title
k8s-ci-robot
added
the
do-not-merge/work-in-progress
|
Hi @benjaminapetersen 👋 v1.35 Communications team here, @sohankunkerkar as author of #52900, I'd like you to be a writing buddy for @benjaminapetersen on this PR. Please:
|
|
Hi @benjaminapetersen 👋 -- this is Graziano (@graz-dev) from the v1.35 Communications Team! Just a friendly reminder that we are approaching the feature blog "ready for review" deadline: Friday 21st November. We ask you to have the blog PR in non-draft state, and all write-up to be complete, so that we can start the blog review from SIG Docs Blog team. If you have any questions or need help, please don't hesitate to reach out to me or any of the Communications Team members. We are here to help you! |
|
Sorry @benjaminapetersen the correct deadline for "Feature Blog Ready for Review" is Monday 24 November. Sorry, my bad :( |
benjaminapetersen
force-pushed
the
kep-5284-constrained-impersonation-blog
branch
from
48614af to
7fb23ae
Compare
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
k8s-ci-robot
added
size/L
benjaminapetersen
changed the title
k8s-ci-robot
removed
the
do-not-merge/work-in-progress
lmktfy
left a comment
lmktfy
left a comment
There was a problem hiding this comment.
@sohankunkerkar I've jumped in to provide a review.
@benjaminapetersen here you go. I get the sense this might be AI-written. Whether or not that's the case, I suggest doing rewrites in the places where it reads like AI writing.
I have also suggested many changes to align this article to our style guide. Doing that will help readers make sense of what parts are verbs, what parts are namespaces, etc.
| [Ben Petersen](https://github.com/benjaminapetersen) (Microsoft) | ||
| --- | ||
|
|
||
| ## Constrained Impersonation: Prentending but Without the Fraud! |
There was a problem hiding this comment.
| ## Constrained Impersonation: Prentending but Without the Fraud! |
We put the title at the top of the page using automation.
|
|
||
| ## Constrained Impersonation: Prentending but Without the Fraud! | ||
|
|
||
| The word "impersonation" tends to elicit bad vibes. In a world where |
There was a problem hiding this comment.
| The word "impersonation" tends to elicit bad vibes. In a world where | |
| The word _impersonation_ tends to elicit bad vibes. In a world where |
|
|
||
| The word "impersonation" tends to elicit bad vibes. In a world where | ||
| security threats lurk around every corner, rarely do we think of impersonation | ||
| as a good thing. But this release we are here to give you some new tools |
There was a problem hiding this comment.
| as a good thing. But this release we are here to give you some new tools | |
| as a good thing. But this release, I am here to give you some news | |
| about tools |
I changed "we" here to I because there is only one author; see https://kubernetes.io/docs/contribute/blog/article-submission/#article-content and https://kubernetes.io/docs/contribute/style/style-guide/#avoid-using-we
| You think fraud, spam calls, or that one colleague who can perfectly copy | ||
| your on-call voice. In Kubernetes, though, impersonation is a very real and | ||
| very useful capability. And now, with constrained impersonation, it’s also a | ||
| lot safer. |
There was a problem hiding this comment.
| lot safer. | |
| When you read "impersonation", you perhaps don’t think _security feature_. | |
| You think fraud, spam calls, or that one colleague who can perfectly copy | |
| your on-call voice. In Kubernetes, though, [impersonation](/docs/reference/access-authn-authz/authentication/#user-impersonation) is a very real and | |
| very useful capability. And now, with constrained impersonation, it's also a | |
| lot safer. |
Hyperlink is optional but recommended.
| very useful capability. And now, with constrained impersonation, it’s also a | ||
| lot safer. | ||
|
|
||
| This post walks through what constrained impersonation is, how it works under |
There was a problem hiding this comment.
| This post walks through what constrained impersonation is, how it works under | |
| This post walks through what _constrained impersonation_ is, how it works under |
| ## Why this is safer (and still backwards compatible) | ||
|
|
||
| Constrained impersonation is designed to be **additive** and **opt-in**: | ||
|
|
||
| - If you do nothing, legacy impersonation keeps working as before. | ||
| - You can enable the `ConstrainedImpersonation` feature gate, then start | ||
| granting the new verbs to specific controllers or workflows. |
There was a problem hiding this comment.
This reads like an LLM wrote it, probably Anthropic Claude 4. If that's true, I recommend a reword to sound more like a human.
| verbs: ["impersonate-on:user-info:get"] | ||
| ``` | ||
|
|
||
| Bind these to the deputy service account. Now, when the deputy impersonates a |
There was a problem hiding this comment.
| Bind these to the deputy service account. Now, when the deputy impersonates a | |
| Bind these to the deputy controller's ServiceAccount. Now, when the deputy impersonates a |
|
|
||
| - Users to keep control over *what they are allowed to do*. | ||
| - The deputy to act "as the user" for just this one action, so audit logs and | ||
| admission behave as if the user did it themselves. |
There was a problem hiding this comment.
| admission behave as if the user did it themselves. | |
| admission behave as if the user did it themselves. |
| 1. Give the deputy permission to impersonate user identities using | ||
| `impersonate:user-info`. |
There was a problem hiding this comment.
| 1. Give the deputy permission to impersonate user identities using | |
| `impersonate:user-info`. | |
| 1. Give the deputy controller permission to impersonate user identities, using | |
| **impersonate:user-info**. |
| - Impersonate **its own node**, and | ||
| - Use that impersonation only to `list` Pods as allowed by the role. | ||
|
|
||
| It does *not* become an all-powerful node or cluster admin. |
There was a problem hiding this comment.
| It does *not* become an all-powerful node or cluster admin. | |
| It does **not** become an all-powerful node or cluster admin. |
lmktfy
left a comment
lmktfy
left a comment
There was a problem hiding this comment.
@sohankunkerkar I've jumped in to provide a review.
@benjaminapetersen here you go. I get the sense this might be AI-written. Whether or not that's the case, I suggest doing rewrites in the places where it reads like AI writing.
I have also suggested many changes to align this article to our style guide. Doing that will help readers make sense of what parts are verbs, what parts are namespaces, etc.
| security threats lurk around every corner, rarely do we think of impersonation | ||
| as a good thing. But this release we are here to give you some new tools | ||
| to make impersonating users, groups, service accounts and nodes as exciting | ||
| as it sounds, but without the fraud! |
There was a problem hiding this comment.
as it sounds, but without the fraud!
Funny, but perhaps a little too informal
| When you hear "impersonation", you probably don’t think "security feature". | ||
| You think fraud, spam calls, or that one colleague who can perfectly copy |
There was a problem hiding this comment.
This is redundant given the first paragraph, and it feels a little repetitive
| Spoiler: we’re not giving your controllers a fake mustache and a stolen | ||
| passport. We’re giving them a tightly scoped, auditable permission slip. |
There was a problem hiding this comment.
leaning a little heavily on the "double-meaning of impersonation" bit. As a joke it merits one usage, and maybe a callback in the closing line 😁
| The word "impersonation" tends to elicit bad vibes. In a world where | ||
| security threats lurk around every corner, rarely do we think of impersonation | ||
| as a good thing. But this release we are here to give you some new tools | ||
| to make impersonating users, groups, service accounts and nodes as exciting | ||
| as it sounds, but without the fraud! | ||
|
|
||
| When you hear "impersonation", you probably don’t think "security feature". | ||
| You think fraud, spam calls, or that one colleague who can perfectly copy | ||
| your on-call voice. In Kubernetes, though, impersonation is a very real and | ||
| very useful capability. And now, with constrained impersonation, it’s also a | ||
| lot safer. |
| - `Impersonate-Uid` | ||
| - `Impersonate-Extra-*` | ||
|
|
||
| And at the `kubectl` level, with flags like `--as` and `--as-group`. |
|
|
||
| --- | ||
|
|
||
| ## The problem: great for humans, too scary for controllers |
There was a problem hiding this comment.
I don't think it is great for humans either.
| kubectl --as=panda@myfavoritebears.com get pods -n prod | ||
| ``` | ||
|
|
||
| If this works, you know that Panda can list Pods in `prod`. If it fails, you |
There was a problem hiding this comment.
| If this works, you know that Panda can list Pods in `prod`. If it fails, you | |
| If this works, you know that `panda` can list `pods` in `prod`. If it fails, you |
|
|
||
| ## The problem: great for humans, too scary for controllers | ||
|
|
||
| Legacy impersonation is intentionally powerful. A cluster admin might use it |
There was a problem hiding this comment.
I don't think it was ever truly intentional to not have scoping.
| 1. **Check: can you impersonate this identity at all?** | ||
|
|
||
| SAR for "who" you can impersonate, for example: | ||
|
|
||
| ```yaml | ||
| apiVersion: authorization.k8s.io/v1 | ||
| kind: SubjectAccessReview | ||
| spec: | ||
| resourceAttributes: | ||
| group: authentication.k8s.io | ||
| resource: users | ||
| name: panda | ||
| verb: impersonate:user-info | ||
| user: system:serviceaccount:default:deputy | ||
| ``` | ||
|
|
||
| If this fails, the request is denied (or falls back to legacy | ||
| impersonation, depending on how you’ve configured things). | ||
|
|
||
| 2. **Check: what are you allowed to do *via* impersonation?** |
There was a problem hiding this comment.
You have the order of the checks backwards.
| verbs: ["impersonate-on:associated-node:list"] | ||
| ``` | ||
|
|
||
| You bind those roles to your node agent’s service account. |
There was a problem hiding this comment.
Include the actual bindings as the scoping matters.
|
|
||
| ## Example: a deputy controller acting for users | ||
|
|
||
| Another story from the KEP: a "deputy" controller that opens VM consoles on |
There was a problem hiding this comment.
I don't know if the story coming from the KEP is relevant.
|
|
||
| - Much smaller blast radius if a controller is compromised. | ||
| - Clear RBAC intent: "this thing can impersonate X, but only to do Y on Z". | ||
| - Better audit information about *why* an impersonation was allowed. |
There was a problem hiding this comment.
Include an explicit section for migrating from the old to the new.
| ## When should you use constrained impersonation? | ||
|
|
||
| You should consider constrained impersonation when: | ||
|
|
||
| - A controller needs to act *as* a user or node, but only for a narrow set of | ||
| actions. | ||
| - You want audit logs to show real users (or nodes) as the actor, even though | ||
| controllers are making the calls. | ||
| - You’d like to stop handing out raw `impersonate` and move toward | ||
| least-privilege delegation. | ||
|
|
||
| You probably don’t need constrained impersonation for: | ||
|
|
||
| - One-off human debugging as a cluster admin using `kubectl --as`. | ||
| - Simple clusters where impersonation isn’t used at all. | ||
|
|
||
| But as clusters grow, controllers multiply, and security teams ask sharper | ||
| questions like, "Why does this CNI daemonset effectively have admin | ||
| privileges?", constrained impersonation gives you a better answer than, | ||
| "Because it was convenient at the time." |
There was a problem hiding this comment.
I disagree with this section, you should use constrained impersonation always once it is available.
github-project-automation
Bot
moved this from Needs Triage
to Changes Requested
in SIG Auth
|
@benjaminapetersen can you please take a look to the pending suggestions? |
|
@graz-dev you bet. I'm still targeting polishing this off now that I'm back from the holidays. |
|
Unfortunately this post can't be published on time to fit into the feature blog schedule. |
|
Ok great, I work with SIG-Auth all the time, should not be a problem to polish it off for outside the 1.35 release window instead. We'd love to keep getting the auth features more accessible, they can tend to be dense in the documentation! |
|
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
k8s-ci-robot
added
the
lifecycle/stale
7 participants
Feature blog post for KEP 5284 constrained impersonation: alpha.
KEP Issue: kubernetes/enhancements#5284
/area blog
/sig auth
cc @enj
Description
Issue
Closes: #