CRD validation resource immutable

[fudali113]

Is this a BUG REPORT or FEATURE REQUEST?:
FEATURE REQUEST

Uncomment only one, leave it on its own line:

/kind bug
/kind feature
/kind feature

What happened:

What you expected to happen:

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

Anything else we need to know?:

I want some of my fields to be immutable in CRD, can I do that?

Environment:

• Kubernetes version (use kubectl version):
• Cloud provider or hardware configuration:
• OS (e.g. from /etc/os-release):
• Kernel (e.g. uname -a):
• Install tools:
• Others:

[mkumatag]

/sig api-machinery

[mkumatag]

what do you mean by immutable? do you want to have something you don't want to change after creating it?

[fudali113]

Yes，i want to some field can't be change。Is there any way? @mkumatag

[nikhita]

Yes，i want to some field can't be change。Is there any way?

No, there is no way to mark fields as immutable right now.

OpenAPI schema does have a construct called readOnly (https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#fixed-fields-20) but we don't support that right now. Would need to investigate if we could indeed support it.

/area custom-resources
/cc @sttts

[fedebongio]

/cc @mbohlool

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[nikhita]

/remove-lifecycle stale

…

On Mon, Oct 8, 2018 at 2:08 AM fejta-bot ***@***.***> wrote: Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with /close. Send feedback to sig-testing, kubernetes/test-infra and/or fejta <https://github.com/fejta>. /lifecycle stale — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#65973 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APXA0BbgLdKtoHwZQ5WS_5tD18EFoy8Sks5uimZhgaJpZM4VHqSR> .

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[zliang-min]

Will this feature be considered to be implemented? This is quite useful, just like the native objects in kubernetes, not all fields are mutable after the object is created. For CRDs, there will be no different.

[mbohlool]

You can use admission webhooks to validate any change including making sure the field is not changed. We may consider dedicated validation webhook in future but for now Admission webhooks do the job.

[zliang-min]

For sure webhook is an option here. But IMHO webhooks are heavy (compared to specifying a field in the CRD yaml file), and most likely for more complicated cases, like the validation might involves some external API calls to some other services. It makes more sense to me that simple validations like readOnly should be handled by CRD.

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[ghost]

It would be fantastic to get this implemented as a none webhook based solution. The read-only could be used to allow initialization, then after the field becomes immutable.

[antonlisovenko]

I absolutely support this feature. Webhooks require long time to develop and support, but we meet the use case of immutable fields again and again, the easy way is to add the field into status and mark the CR as failed in case the spec field has diverged but putting the fields to status only to support contract is a quite ugly way

[dgoodwin]

👍 I think this would be a very high value and logical feature to support. We've done the webhook path and indeed it was a big investment, and feels disproportionately heavy handed. All we've needed to use it for thus far was making fields immutable once set.

[sttts]

I agree this would be awesome. But for being able to do that we have to restrict the OpenAPI features in a sane way that read-only can be derived in a consistent way for every field. We are working on this.

[adevjoe]

Any progress or design doc on this?

[ChenLingPeng]

we need this feature

[arkhipovds]

We need this feature

[sttts]

With CEL you will be able to express immutability. cc @jpbetz @cici37

[jpbetz]

With CEL you will be able to express immutability. cc Joe Betz Cici Huang

We have some statements in the KEP about this:

For immutability use case, validator will have access to the existing version of the object. This will be accessible to CEL via the old identifier. ...

But this won't be in the alpha for 1.23, and we need to revisit the design and look through the edge cases a lot more carefully before we commit to implementing.

cc @liggitt

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[abstrask]

/remove-lifecycle stale

[franpog859]

Hello, any news on this topic? It'd be great to have it!

[apelisse]

We're working on a kep, can you share what your goals are? Now is the best time to ask! ;-)

[franpog859]

@apelisse , I'm implementing an operator that uses a CR to obtain some information needed to create/ update/ delete other different resources. Some specs of these resources are not upgradeable. I think it'd be good to make these CR fields immutable so the user cannot trigger the operator with the changes that cannot be properly maintained anyway. An error while trying to edit an immutable field would solve the problem with inconsistency between the CR and the spec of the other resources and would make the validation in the operator much easier

[apelisse]

cc @alexzielenski

[jpbetz]

Since I don't think it's been mentioned on this issue yet, I wanted to point out that x-kubernetes-validations transition rules can be used to enforce CRD immutability. The main caveat is that the feature is currently alpha. It is slated for beta in 1.25.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[m-yosefpor]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[apelisse]

We should be able to close this now, no? I'll pro-actively close, let me know in the comments if you disagree.

[alexzielenski]

Relevant blog post on this topic: https://kubernetes.io/blog/2022/09/29/enforce-immutability-using-cel/