Improve 'Seccomp defaulting' feature name

[saschagrunert]

We're now rephrasing those two paragraphs to avoid confusing readers.

Follow-up on #34640 (comment)

[netlify]

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

Name	Link
🔨 Latest commit	641a8e2
🔍 Latest deploy log	https://app.netlify.com/sites/kubernetes-io-vnext-staging/deploys/62d6575ee7041c000884406f

[pjbgf]

Good shout! It does make it clearer for the reader.

/lgtm

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: e41ab89e2948f61b2c8cf0e79b3e3dcceb7b53be

[sftim]

As much as possible, we should write the docs as if the feature is already GA. We still need to mention the name of the related feature gate until graduation to stable, but we should try to minimize those mentions.

Writing as if the feature is stable makes it easier to adapt at graduation time, and helps makes those docs closer to our timeless docs ideal.

[sftim]

I'm not going to /lgtm cancel this, but I do disagree with exposing the feature gate name as jargon that we expect readers to recognize.

[pjbgf]

we should write the docs as if the feature is already GA

I think this may be an exception to the rule, given that this functionality is transitional by nature and will become a non-feature as soon as it GAs.

Given the security implications of assuming this is enabled when it may not be, I also don't think the timeless docs approach should apply, or we risk leaving users that potentially don't know the ins and outs of Seccomp worse off.

But I am keen to hear what other folks may think about this.

[sftim]

will become a non-feature as soon as it GAs

I don't understand that, to be honest.

• We should clearly document how Kubernetes in respect of the behavior that the feature gate affects (the default seccomp profile for Pods that don't explicitly specify one). This is the key thing to document.
  For example, I'd expect the default seccomp profile to be mentioned in https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
• Whilst the feature gate exists, we should also document how to toggle the feature and the implications of doing so. Pages that mention the default seccomp profile can link to the docs about configuring what that default is.
  • Once the feature graduates, we remove this part but leave in the docs that explain the default seccomp profile.

[sftim]

Something like:

Kubernetes {{< skew currentVersion >}} lets you configure the seccomp profile that applies when the
spec for a Pod doesn't define a specific seccomp profile. This is a beta feature and …

[saschagrunert]

Good, thank you for the input. I changed the paragraphs a bit.

[sftim]

Thanks

/lgtm
/approve

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 77a127835ffb589f0c4dd2603e54fc131235c940

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: pjbgf, 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/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]

I didn't notice that this targeted dev-1.25. It's fine, but we could actually have targeted main here.

Also OK to cherry-pick this to make an equivalent change to main.

[saschagrunert]

I didn't notice that this targeted dev-1.25. It's fine, but we could actually have targeted main here.

Also OK to cherry-pick this to make an equivalent change to main.

Changing it in main would cause merge conflicts later on, right?

[sftim]

Git can automatically solve a merge if we cherry pick these exact changes.