KEP 5933: Add x-kubernetes-sensitive-data marker for CRD fields by trofimovdals · Pull Request #5937 · kubernetes/enhancements

trofimovdals · 2026-02-25T09:52:34Z

Introduces x-kubernetes-sensitive-data vendor extension that enables field stripping on get/list/watch for unauthorized callers and unconditional masking of sensitive values in audit log entries.

One-line PR description: Add support for marking CRD fields as sensitive with RBAC-gated access, and audit log masking

Issue link: CRD Sensitive Data Protection #5933

Signed-off-by: dmitry.trofimov <dmitry.trofimov@flant.com>

k8s-ci-robot · 2026-02-25T09:52:45Z

Hi @trofimovdals. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

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.

k8s-ci-robot · 2026-02-25T09:52:46Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: trofimovdals
Once this PR has been reviewed and has the lgtm label, please assign fedebongio for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

keps/sig-api-machinery/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

lmktfy · 2026-03-17T08:06:46Z

keps/sig-api-machinery/5933-crd-sensitive-data/kep.yaml

+  - "@sprait"
+owning-sig: sig-api-machinery
+participating-sigs:
+  - sig-auth


SIG Security too?

lmktfy · 2026-03-17T08:07:52Z

keps/sig-api-machinery/5933-crd-sensitive-data/README.md

+- PATCH request audit masking is technically challenging, requiring JSON path analysis of patch bodies.
+
+## Alternatives
+


We should note that people could use a Secret instead (even if we rule out that alternative); it is a broadly viable option here.

thanks, added to alternatives

lmktfy · 2026-03-17T08:09:36Z

keps/sig-api-machinery/5933-crd-sensitive-data/README.md

+- Returned **in full** to every authenticated caller that can `get` the resource, even if the caller only needs non-sensitive fields.
+- Logged **in cleartext** in audit log entries, creating a compliance risk.
+
+There is no first-class Kubernetes primitive that lets a CRD author say "this field is sensitive — treat it accordingly".


That's true, and I note the non goals, but having a built in API with these properties would also be really convenient.

this KEP is intentionally scoped to CRDs for now, while aiming to keep the design compatible with a more general built-in solution later

lmktfy · 2026-03-17T08:10:40Z

keps/sig-api-machinery/5933-crd-sensitive-data/README.md

+- PATCH masking in audit is more complex than GET/PUT masking because the patch body must be parsed and individual values replaced by path.
+
+### Risks and Mitigations
+


If I get an object and write it back with a PUT, do I lose data? How's that risk managed?

Good catch. Yes, this is a potential data-loss scenario for callers that can update the resource but cannot read /sensitive, since they would receive a redacted representation and could overwrite hidden fields via PUT. I updated the KEP to explicitly document this risk and to mitigate it by rejecting full-object updates from such callers.

This case does not even make sense. A patch with {} payload is a read. Everybody with write permissions has inherently (sensitive) read too.

And it highlights another problem: authz can fail without the SAR caller to notice (think of authz webhooks). So a read would degrade to a masked read. And then every write is a potential data loss without noticing and without a way to know.

sttts · 2026-03-31T07:43:29Z

keps/sig-api-machinery/5933-crd-sensitive-data/README.md

+- Returned **in full** to every authenticated caller that can `get` the resource, even if the caller only needs non-sensitive fields.
+- Logged **in cleartext** in audit log entries, creating a compliance risk.
+
+There is no first-class Kubernetes primitive that lets a CRD author say "this field is sensitive — treat it accordingly".


Wasn't it always considered an anti-pattern in core types (in k/k) to have secret data outside of secrets in any type? Why should we handle CRDs differently?

I remember in OpenShift we had a couple of resources that as a whole were considered sensitive (because mistakes were made not to follow the rule long ago).

So my gut feeling here is that we are building a feature to mitigate "wrong" usage. By design there are secrets in Kube as the primary (or only) resource that this senstivie.

sttts · 2026-03-31T07:46:20Z

keps/sig-api-machinery/5933-crd-sensitive-data/README.md

+    verbs: ["get", "list", "watch"]
+```
+
+Callers **without** this permission receive the resource with sensitive fields removed (set to `null` / omitted). Callers **with** this permission receive the full resource.


different behaviour depending on authz is not a good pattern. Assuming we want a feature like described, we would want very explicit list/get options for this, or a different resource path (subresource).

Also note that there are more dragons deep in the storage stack: watchlist caches events in marshalled form, and fans out to all consumers. We cannot differentiate between trusted and non-trusted there.

sttts · 2026-03-31T07:48:11Z

keps/sig-api-machinery/5933-crd-sensitive-data/README.md

+
+Callers **without** this permission receive the resource with sensitive fields removed (set to `null` / omitted). Callers **with** this permission receive the full resource.
+
+Write access to sensitive fields is controlled by standard `create`/`update`/`patch` verbs on the main resource — no additional write-side subresource is required.


isn't this contradicting the direction of the role above? Being allowed to write because of verb: * permissions, but able to read sensitive data is very odd. Note that every update is also a read.

Thinking out loud: databases/non-sensitive-thing would give much cleaner behaviour. And then the client would have to ask for the sanitized versions. It would be a normal subresource with normal subresource semantics.

sttts · 2026-03-31T07:54:06Z

keps/sig-api-machinery/5933-crd-sensitive-data/README.md

+
+- `audit.LogRequestObject()` and `audit.LogResponseObject()` invoke an `ObjectTransformer` registered by the CRD handler.
+- The transformer deep-copies the object and calls `MaskSensitiveFields()`, replacing each sensitive value with `"******"`.
+- PATCH request bodies containing sensitive paths are masked in the same way.


how? patch could be json patch where it is not that clear how to mask.

KEP:5933-crd-sensitive-data

90c2967

Signed-off-by: dmitry.trofimov <dmitry.trofimov@flant.com>

k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Feb 25, 2026

k8s-ci-robot requested a review from apelisse February 25, 2026 09:52

k8s-ci-robot added the kind/kep Categorizes KEP tracking issues and PRs modifying the KEP directory label Feb 25, 2026

k8s-ci-robot requested a review from sttts February 25, 2026 09:52

k8s-ci-robot added sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Feb 25, 2026

trofimovdals mentioned this pull request Feb 25, 2026

CRD Sensitive Data Protection #5933

Open

4 tasks

lmktfy reviewed Mar 17, 2026

View reviewed changes

update "Risks and Mitigations"

e43732d

k8s-ci-robot added size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Mar 24, 2026

trofimovdals requested a review from lmktfy March 27, 2026 10:03

sttts reviewed Mar 31, 2026

View reviewed changes

		- PATCH request audit masking is technically challenging, requiring JSON path analysis of patch bodies.

		## Alternatives

		- PATCH masking in audit is more complex than GET/PUT masking because the patch body must be parsed and individual values replaced by path.

		### Risks and Mitigations


		Callers without this permission receive the resource with sensitive fields removed (set to `null` / omitted). Callers with this permission receive the full resource.

		Write access to sensitive fields is controlled by standard `create`/`update`/`patch` verbs on the main resource — no additional write-side subresource is required.

Conversation

trofimovdals commented Feb 25, 2026

Uh oh!

k8s-ci-robot commented Feb 25, 2026

Uh oh!

k8s-ci-robot commented Feb 25, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sttts Mar 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

sttts Mar 31, 2026 •

edited

Loading