feat: add configurable field-level restrictions for container and pod overrides

[tolusha]

What does this PR do?

This PR adds a configurable restriction system for container-overrides and pod-overrides DevWorkspace attributes. Cluster admins can define deny rules in DevWorkspaceOperatorConfig to block specific fields (e.g.
hostNetwork, securityContext.privileged) or specific values (e.g. restartPolicy=Always) from being set via overrides. On Kubernetes, security-sensitive defaults are denied out of the box — such as privileged containers,
running as root, host networking, and hostPath volumes — to match the restrictions that OpenShift enforces natively via SCCs

What issues does this PR fix or reference?

N/A

Is it tested? How?

Create a DevWorkspace with container-overrides, for instance:

attributes:
  container-overrides:
    securityContext: {privileged: true}

PR Checklist

• E2E tests pass (when PR is ready, comment /test v8-devworkspace-operator-e2e, v8-che-happy-path to trigger)
  • v8-devworkspace-operator-e2e: DevWorkspace e2e test
  • v8-che-happy-path: Happy path for verification integration with Che

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: tolusha
Once this PR has been reviewed and has the lgtm label, please assign dkwon17 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:

• OWNERS

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

[coderabbitai]

Warning

Review limit reached

@tolusha, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 14 minutes and 3 seconds. Learn how PR review limits work.

Your organization has run out of usage credits. Purchase more credits in the billing tab to continue.

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 89d9825d-bbd4-4eda-bb6e-23defb213d8f

📥 Commits

Reviewing files that changed from the base of the PR and between cdc8050 and fd4d54f.

📒 Files selected for processing (27)

• apis/controller/v1alpha1/devworkspaceoperatorconfig_types.go
• apis/controller/v1alpha1/zz_generated.deepcopy.go
• controllers/workspace/devworkspace_controller.go
• deploy/bundle/manifests/controller.devfile.io_devworkspaceoperatorconfigs.yaml
• deploy/deployment/kubernetes/combined.yaml
• deploy/deployment/kubernetes/objects/devworkspaceoperatorconfigs.controller.devfile.io.CustomResourceDefinition.yaml
• deploy/deployment/openshift/combined.yaml
• deploy/deployment/openshift/objects/devworkspaceoperatorconfigs.controller.devfile.io.CustomResourceDefinition.yaml
• deploy/templates/crd/bases/controller.devfile.io_devworkspaceoperatorconfigs.yaml
• docs/dwo-configuration.md
• pkg/config/common_test.go
• pkg/config/defaults.go
• pkg/config/sync.go
• pkg/library/container/container.go
• pkg/library/container/container_test.go
• pkg/library/overrides/container_restrictions.go
• pkg/library/overrides/container_restrictions_test.go
• pkg/library/overrides/containers.go
• pkg/library/overrides/containers_test.go
• pkg/library/overrides/pod_restrictions.go
• pkg/library/overrides/pod_restrictions_test.go
• pkg/library/overrides/pods.go
• pkg/library/overrides/pods_test.go
• pkg/library/overrides/restrictions.go
• pkg/library/overrides/testdata/container-overrides/container-cannot-set-restricted-fields.yaml
• pkg/provision/storage/commonStorage.go
• pkg/provision/storage/perWorkspaceStorage.go

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch overriderestrictions

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[tolusha]

Hi! I'm che-ai-assistant — I help with your pull requests.

Available commands:

• /che-ai-assistant generate-che-doc — Generate a documentation PR based on this PR's changes
• /che-ai-assistant ok-pr-review — Run a comprehensive PR review (summary, code review, deep review, impact analysis)
• /che-ai-assistant help — Show this help message

[dkwon17]

For container_restrictions.go and pod_restriction.go, I am a bit concerned because we are calling checkString(<field>) for so many container/pod fields.

Have you considered iterating over the fields in DeniedContainerOverrideFields and DeniedPodOverrideFields and checking if those fields exist in the container/pod instead?

Please correct me if I'm wrong but it seems like this PR is checking this the other way around (going over all possible container/pod fields, and checking DeniedContainerOverrideFields/DeniedPodOverrideFields)

[tolusha]

Have you considered iterating over the fields in DeniedContainerOverrideFields and DeniedPodOverrideFields and checking if those fields exist in the container/pod instead?

It is a way complicated.

[tolusha]

It should n`t take much resources

func (r deniedFieldRules) checkString(fieldName string, fieldValue *string) error {
	if fieldValue == nil || *fieldValue == "" {
		return nil
	}
	...