v1.23 blog post: Pod Security Admission Graduates to Beta #30502

jimangel · 2021-11-16T03:47:39Z

Draft blog post on behalf of SIG Auth for the v1.23 release around Pod Security Admission (supporting KEP).

~~I also had an issue with my demo until I changed runtimeClassNames to runtimeClasses. Potentially someone can weigh in on that during tech review.~~

Next Steps:

Update blog & official docs URLs (in content and at bottom)
Update ~~kindest/node:v1.23.0 to the correct sha256 tag~~ (using latest for now)
Identify the "official" blog release date (update filename / front matter)
SIG Docs review
SIG Auth tech review

Preview quick link: https://deploy-preview-30502--kubernetes-io-main-staging.netlify.app/blog/2021/12/09/pod-security-admission-beta/

/hold (until all steps are complete)
/cc @lachie83 @reylejano @liggitt

netlify · 2021-11-16T03:47:44Z

👷 Deploy Preview for kubernetes-io-vnext-staging processing.

🔨 Explore the source changes: b4b25c6

🔍 Inspect the deploy log: https://app.netlify.com/sites/kubernetes-io-vnext-staging/deploys/61943df67b69390007d34f2c

liggitt · 2021-11-16T03:51:09Z

runtimeClassNames typo fixed in https://github.com/kubernetes/website/pull/30274/files

jimangel · 2021-11-16T03:55:53Z

runtimeClassNames typo fixed in https://github.com/kubernetes/website/pull/30274/files

Perfect! As long as it's technically correct, it will have no impact to the release process (and fixes the inflight v1.23 docs code section too).

Edit: Removed files w/ typo corrections in PR to make for easy, single file, review. We might need to still retroactively patch the docs in dev-1.23 or main depending on when we see this.

jlbutler · 2021-11-16T15:13:28Z

Should this be filed against main rather than the dev branch?

/cc @karenhchu

content/en/blog/_posts/2021-12-15-pod-security-admission-psa-beta.md

sftim

Some early feedback. I realise it's a WIP PR so please see everything here as a suggestion only.

content/en/blog/_posts/2021-12-15-pod-security-admission-psa-beta.md

sftim · 2021-11-16T17:26:27Z

We should get a tech review on this from SIG Auth (which I hope will be easy to get because of the eyes on this already)

lachie83 · 2021-11-16T19:22:52Z

We should get a tech review on this from SIG Auth (which I hope will be easy to get because of the eyes on this already)

I will reach out to @ritazh from SIG Auth to see who can help with tech review.

jimangel · 2021-11-16T19:33:01Z

Should this be filed against main rather than the dev branch?

If we know the blog release date before the Kubernetes version is released, it shouldn't matter. As it could merge and not go live until the date.

I think you're right though, historically we've opened blogs against main since they would get merged / go live post-release.

I'm good with either option, let me know a decision and I can act. I would love someone closer to the blog subproject to weigh in with a suggestion.

Edit: Moved to main based on Tim's recommendation!

tallclair

Awesome, thanks for writing this!

content/en/blog/_posts/2021-12-15-pod-security-admission-psa-beta.md

tallclair · 2021-11-16T18:17:58Z

content/en/blog/_posts/2021-12-15-pod-security-admission-psa-beta.md

+
+It's important to note that Pod Security Admission doesn't have complete feature parity with the deprecated Pod Security Policy. Specifically, it doesn't have the ability to `mutate` or change Kubernetes resources to auto-remediate a policy violation on behalf of the user. Additionally, it doesn't provide fine-grain control over each allowed field and value within a pod specification or any other Kubernetes resource that you may wish to evaluate. If you need more fine-grained policy control then take a look at the [Gatekeeper](https://github.com/open-policy-agent/gatekeeper) project which supports such use cases.
+
+Pod Security Admission also adheres to Kubernetes best practices of declarative object management by denying resources that violate the policy. This requires resources to be updated in source repositories, and tooling to be updated prior to being deployed to Kubernetes.


I'm not sure I understand this sentence. Isn't this also true of PSP (and most validating admission controllers, for that matter)?

If you're referring to "Pod Security Admission also adheres to Kubernetes best practices of declarative object management by denying resources that violate the policy. This requires resources to be updated in source repositories, and tooling to be updated prior to being deployed to Kubernetes."

The intention is to call out the explicit declarative nature of Pod Security (and any admission controller), whereas PSP had the ability to introspect CRI information to make decisions. For example, if you built a container as non-root, and didn't include a runAsUser, it would pass PSP but fail Pod Security (circumstances depending).

Open to alternative ways to draw attention to this paradigm shift from PSP to "normal" admission behavior.

content/en/blog/_posts/2021-12-15-pod-security-admission-psa-beta.md

sftim · 2021-11-16T21:32:30Z

If we know the blog release date before the Kubernetes version is released, it shouldn't matter. As it could merge and not go live until the date.
I think you're right though, historically we've opened blogs against main since they would get merged / go live post-release.

I would have this ready-to-merge but not merge it until the release is confirmed. And I'd target main.
In essence, we shouldn't merge any announcement for publication until we are certain of the publication date.

sftim · 2021-11-19T10:09:15Z

It would also be ideal for both to be merged / published around the same dates so that they are available for consumption and most importantly the cross-links work

The easy answer is for us to have the tutorial page and the blog article both ready to go on v1.23 release day, and then manually merge both of these on a different day post release.

Slightly more faff, but possible: publish the tutorial at release time without a reference to the blog article, have the blog scheduled, have a follow-up PR ready that hyperlinks from the tutorial to the blog article as further reading.

sftim

I think this could go in as-is, and the changes I'm suggesting here (are what I think would) add polish to an already good article.

content/en/blog/_posts/2021-12-15-pod-security-admission-beta.md

sftim · 2021-11-28T19:21:37Z

content/en/blog/_posts/2021-12-15-pod-security-admission-beta.md

+
+### When to use `warn`?
+
+The typical uses for `warn` are:


Suggested change

The typical uses for `warn` are:

The typical uses for `warn` are to get ready for a future change where you want to enforce

a different policy. The most two common cases would be:

How about case 3, you're not enforcing any policy yet, and you want to preview the impact? I think that's a good use for warn (maybe also: delete all existing Pods once you do).

I should add that I haven't actually tried Pod Security admission in any real-world cluster with a real world workload on it, so please take that in mind when considering my suggestions.

How about case 3, you're not enforcing any policy yet, and you want to preview the impact? I think that's a good use for warn

That's sort of the same as "warn at a stricter level", where enforce is privileged and warn is baseline or restricted. If you think it's clearer to explicitly call that out as a third case, that's fine

(maybe also: delete all existing Pods once you do).

If you're looking to check a new policy non-disruptively, deleting existing pods is not the way to do it :-)

content/en/blog/_posts/2021-12-15-pod-security-admission-beta.md

sftim · 2021-12-05T22:38:15Z

@jimangel I think this is ready for review, right?

/approve
The intent of this PR is a change I am very happy to see made.

PushkarJ · 2021-12-06T00:17:14Z

@sftim as per your feedback: #30502 (comment) (I think) the tutorial #30422 is now ready to go and currently on /hold for this blog PR to get merged / published.

Namespace level tutorial preview
Cluster level tutorial preview

content/en/blog/_posts/2021-12-15-pod-security-admission-beta.md

jimangel · 2021-12-07T07:17:58Z

This is ready to merge / final review. I just pushed the following changes:

Actionable feedback addressed
TODO's removed
v1.23 links added
Incorporated the future tutorial reference / links (thanks @PushkarJ!)
Modified the file / date to match intended publish date
General clean up / checks

At this point I don't anticipate making any further changes unless requested! Once the build finishes I'll update the preview links.

/cc @lachie83

sftim · 2021-12-08T00:03:53Z

/hold cancel

v1.23 is released, I don't see anything blocking publication.

Co-authored-by: Lachlan Evenson <lachlan.evenson@microsoft.com>

ritazh · 2021-12-08T01:45:38Z

/approve
/lgtm
Thank you everyone for working on this PR! 🎉

k8s-ci-robot · 2021-12-08T01:46:08Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ritazh, sftim

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:

~~content/en/blog/OWNERS~~ [sftim]

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

sftim · 2021-12-08T01:59:21Z

Not sure Prow saw the edited /lgtm from #30502 (comment) so:
/lgtm

k8s-ci-robot · 2021-12-08T01:59:40Z

LGTM label has been added.

Git tree hash: 07950e1abcb37c0ef675c295684026195c6852cc

k8s-ci-robot added this to the 1.23 milestone Nov 16, 2021

k8s-ci-robot requested review from lachie83, liggitt and reylejano November 16, 2021 03:47

k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Nov 16, 2021

k8s-ci-robot added size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. area/blog Issues or PRs related to the Kubernetes Blog subproject language/en Issues or PRs related to English language sig/docs Categorizes an issue or PR as relevant to SIG Docs. labels Nov 16, 2021

k8s-ci-robot requested a review from karenhchu November 16, 2021 15:13