add document for secure-pod-defaults feature and settings #6461
Conversation
✅ Deploy Preview for knative ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
knative-prow
bot
added
the
size/M
evankanderson
left a comment
evankanderson
left a comment
There was a problem hiding this comment.
/assign
Thanks for writing this up! A couple comments, but it's good to have this documented more clearly.
docs/versioned/.nav.yml
Outdated
| - Installing Security-Guard: serving/app-security/security-guard-install.md | ||
| - Security-guard quickstart: serving/app-security/security-guard-quickstart.md | ||
| - Security-Guard example alerts: serving/app-security/security-guard-example-alerts.md | ||
| - SecurePodDefaults: serving/app-security/secure-pod-defaults.md |
There was a problem hiding this comment.
I would move this to "Administration / Configuring Knative / Serving Configuration, around line 280.
Sorry for leaving this section here to confuse -- I think it may be removed altogether soon.
There was a problem hiding this comment.
I suggest to Nader this section because I think it's relevant and we can have documentation in two places.
I'm going to make a separate PR that collapses security guard into a single page. Thus the section becomes about 'Application Security' instead of just exclusive to security guard.
(edit) done: #6464
There was a problem hiding this comment.
As can we move Secure Pod Defaults to the top of the section
There was a problem hiding this comment.
@evankanderson I'll defer to you what content you feel belongs in one spot vs the other
|
|
||
| ## SecurePodDefaults | ||
|
|
||
| Knative Serving provides a `secure-pod-defaults` configuration option that gives operators granular control over pod security defaults, enabling progressive adoption of more secure pod configurations while maintaining backward compatibility with existing workloads. This feature offers three security levels—`disabled`, `root-allowed`, and `enabled` allowing organizations to gradually adopt security best practices without breaking container images that require specific permissions. The default is `disabled` to ensure existing deployments continue to work without modification. |
There was a problem hiding this comment.
I'd be careful about saying "granular control". I'd rather link to Pod Security Standards, and say that it allows the default Service configuration to run in the "restricted" profile without requiring application developers to explicitly set security properties. Another possible phrasing: enabled will default to the values permitted by the "restricted" profile, and root-allowed will default most values to the "restricted" profile while allowing several common application containers to run.
There was a problem hiding this comment.
Actually, I'm wondering if a little bit of philosophy would be useful here. (Defaults should be safe, but k8s defaults aren't always / values should be safe if but specified, but don't block explicit reduction of security stance.)
We may also want to point to k8s Pod Security Admission and/or policy frameworks like OPA gatekeeper and Kyverno for "enforce secure settings" (as opposed to "default to safe"). An additional benefit of these other frameworks is that they cover all types of pods, while secure-pod-defaults only covers Knative pods that haven't thought about security settings.
dprotaso
left a comment
dprotaso
left a comment
There was a problem hiding this comment.
Looks good - some minor stuff
| --- | ||
|
|
||
|
|
||
| ## SecurePodDefaults |
There was a problem hiding this comment.
Can we add a !!! notice/important/warning banner on this page that the current default will be changed in 1.21 and that users should explicitly disable this setting to retain the existing behaviour
Then we can link this section in the 1.20 release notes
There was a problem hiding this comment.
Ooh, good point!
Yes, I think a warning banner would be a good call given that we know we'll be changing this.
|
/assign @evankanderson for further review |
|
Also please see this issue comment: knative/serving#16137 (comment) I realize we might have an opportunity to simplify this a bit in 1.21 |
|
@evankanderson @dprotaso I think I covered all of the comments in the discussion, please take another look note: I moved the page link in the nav.yaml, but didn't move the actual file location because I wasn't sure if github would be able to show the diff and comments, I can move it once you both think its ready. |
|
I think we'll need a big reorganization one day; in the meantime, the nav.yml magic picks up the first place the page appears in the nav bar |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: evankanderson, nader-ziada The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
knative-prow
bot
added
the
approved
|
thanks @nader-ziada |
3 participants
Proposed Changes
/cc @dprotaso