feat: secure-pod-defaults is enabled by default

[kauana]

Fixes #14029

Proposed Changes

• secure-pod-defaults is now enabled by default on the config-features ConfigMap

[kauana]

Hello @psschwei,

I'm working on updating the tests to account for enabling the flag secure-pod-defaults to true by default (follow up to PR #13398). One failing unit test in particular made me think about the interaction between the two flags SecurePodDefaults and PodSpecSecurityContext. While I'm trying to ramp on these changes, I noticed you mentioned having validation issues when you set SecurePodDefaults: enabled which required enabling PodSpecSecurityContext as well.

Just to recap (and to confirm my own understanding), setting PodSpecSecurityContext allows the user to configure some PodSecurityContext fields mentioned here. However, secure-pod-defaults makes it so pods adhere the restricted pod security standard and it allows some parts of PodSecurityContext to be set but to specific values (including setting allowPrivilegeEscalation to false and seccompProfile to RuntimeDefault).

Anyways, I do see a bit of a conflict between these two flags. Perhaps the flag to set PodSpecSecurityContext is now redundant or when SecurePodDefault is enabled it enables PodSpecSecurityContext by default? I would like to heart your thoughts.

[psschwei]

Just to recap (and to confirm my own understanding), setting PodSpecSecurityContext allows the user to configure some PodSecurityContext fields mentioned here. However, secure-pod-defaults makes it so pods adhere the restricted pod security standard and it allows some parts of PodSecurityContext to be set but to specific values (including setting allowPrivilegeEscalation to false and seccompProfile to RuntimeDefault).

I think you're right

Anyways, I do see a bit of a conflict between these two flags. Perhaps the flag to set PodSpecSecurityContext is now redundant or when SecurePodDefault is enabled it enables PodSpecSecurityContext by default? I would like to heart your thoughts.

I think the latter option (SecurePodDefault enabled also enables PodSpecSecurityContext) makes sense for now.

There might be some scenario where someone doesn't want to use our secure defaults or enable the pod security context, so it may make sense to leave in the PodSpecSecurityContext flag, at least for the time being.

cc @evankanderson who also had thoughts on this iirc

[kauana]

I think the latter option (SecurePodDefault enabled also enables PodSpecSecurityContext) makes sense for now.

There might be some scenario where someone doesn't want to use our secure defaults or enable the pod security context, so it may make sense to leave in the PodSpecSecurityContext flag, at least for the time being.

I'm wondering what should be the timeline for making SecurePodDefaults enable PodSpecSecurityContext? This PR is an attempt at making SecurePodDefaults enabled by default (#14029), which would mean PodSpecSecurityContext would also be enabled by default.

Currently, kubernetes.podspec-securitycontext is set to "disabled" by default, with warnings about enabling this feature flag (see here). So, I'm thinking that before we do this, we might want to add a "warning" similar to what Evan did here?

[psschwei]

I'm wondering what should be the timeline for making SecurePodDefaults enable PodSpecSecurityContext?

I think you'd need to do that for this PR, but I'd keep both flags (so that a user could toggle them both off if they so desired).

[dprotaso]

I think the latter option (SecurePodDefault enabled also enables PodSpecSecurityContext) makes sense for now.

We shouldn't do this.

SecurePodDefault should only allow the desired defaults to be set to specific values

Enabling PodSpecSecurityContext gives users way more freedom than SecurePodDefaults intends

[KauzClay]

perhaps the changes in #14363

could be rolled into this PR as well

OR

The test updates and stuff get rolled into #14363 , and this PR just becomes changing the default.

That way we could backport the other changes

[dprotaso]

If #14363 means secure pod defaults is broken when enabled then we should fix it (and I'll cherry-pick it)

I think the scope of this PR should just remain to flipping secure pod defaults from off to on

[knative-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

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

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

Needs approval from an approver in each of these files:

• OWNERS
• pkg/apis/OWNERS

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

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (05e349f) 86.11% compared to head (a3204f1) 86.12%.
Report is 153 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #14168      +/-   ##
==========================================
+ Coverage   86.11%   86.12%   +0.01%     
==========================================
  Files         196      196              
  Lines       14880    14880              
==========================================
+ Hits        12814    12816       +2     
+ Misses       1758     1754       -4     
- Partials      308      310       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[kauana]

/retest

[dprotaso]

/retest

[knative-prow]

@kauana: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
upgrade-tests_serving_main	a3204f1	link	true	/test upgrade-tests

Your PR dashboard.

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/test-infra repository. I understand the commands that are listed here.

[dprotaso]

/hold

see: #14029 (comment)

[github-actions]

This Pull Request is stale because it has been open for 90 days with
no activity. It will automatically close after 30 more days of
inactivity. Reopen with /reopen. Mark as fresh by adding the
comment /remove-lifecycle stale.