Moving Windows security info to new page

[marosset]

Moving Windows security information to a new page

Part of #31428

/label refactor
/sig windows

[netlify]

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

🔨 Explore the source changes: 9b68767

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

[sftim]

/sig security

[sftim]

I've made some suggestions - what do you think @marosset ?

[sftim]

I think this belongs elsewhere, perhaps as a note in https://kubernetes.io/docs/concepts/workloads/pods/#privileged-mode-for-containers ?

Maybe at least restate it there.

[marosset]

Hmm, this is already stated at https://kubernetes.io/docs/concepts/workloads/pods/#privileged-mode-for-containers

If your cluster has the WindowsHostProcessContainers feature enabled, you can create a Windows HostProcess pod by setting the windowsOptions.hostProcess flag on the security context of the pod spec. All containers in these pods must run as Windows HostProcess containers. HostProcess pods run directly on the host and can also be used to perform administrative tasks as is done with Linux privileged containers.

Should we just remove mention of it here?

[sftim]

It's a little bit tidier to use the same or very similar wording in both places; it's also fine to leave them different and then after this merges log a good-first-issue about making the two places match.
(We like to have a nice pool of easily tractable fixes).

[marosset]

I think this would qualify as an easily tractable fix so I can open that issue and add the help-wanted tag after this merges if that could help new contributors get started making PRs into this repo.

[marosset]

/assign @brasmith-ms

[k8s-ci-robot]

@marosset: GitHub didn't allow me to assign the following users: brasmith-ms.

Note that only kubernetes members, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time.
For more information please see the contributor guide

In response to this:

/assign @brasmith-ms

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.

[sftim]

LGTM from a content and style perspective. There are some nits to if you'd like to.

Once you're happy, please squash commits.

[jihoon-seo]

Preview: https://deploy-preview-31851--kubernetes-io-vnext-staging.netlify.app/docs/concepts/security/windows-security/

[marosset]

@sftim I incorporated your feedback and rebased.

[marosset]

TODO: s/perithompson/aravindh

[marosset]

todo: link to https://kubernetes.io/docs/concepts/security/pod-security-standards/#what-profiles-should-i-apply-to-my-windows-pods

[marosset]

todo: update https://kubernetes.io/docs/tasks/configure-pod-container/create-hostprocess-pod/ to reference https://kubernetes.io/docs/concepts/security/pod-security-standards/#what-profiles-should-i-apply-to-my-windows-pod

[tengqm]

Let's get the balls rolling. Approving based the feedback/revision history.
/lgtm
/approve

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 62019ad90a1229c7effce34f430ff3dab242e184

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: tengqm

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 [tengqm]

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

[marosset]

@tengqm Thanks for merging this.
I discussed these PRs and the parent issue during one of the sig-docs community meetings in March.
The we all discussed was to stage all of the PRs that split up intro-windows-in-kubernetes.md in the dev-1.24 branch but hold them until after the initial dev-1.24->main and then do another merge shortly after.
The intentions here was sig-docs leads weren't sure they would have enough bandwidth to adequately review the Windows PRs due to all the dockershim removal work. @sftim, @nate-double-u, and a few others were there as well.
My apologies for not adding a hold here.
Would you all like me to revert this PR or is it OK to keep in dev-1.24?

I'm OK either way.
I'm going to focus on the rest of the items listed in #31428 after 1.24 code freeze.

[sftim]

At this point a revert won't achieve what we'd want (reduced workload for the release docs team). I guess these are OK to live with, and the changes are beneficial.

[sftim]

From SIG Docs side, we could have added a hold and didn't. Sorry about that.

[tengqm]

What I had in mind when kicking this in was: 1. a refactoring work is nontrivial, we will need to achieve the goal in a step by step way; 2. the Windows docs are well maintained so far and people are actively improving them, we are supposed to encourage that; 3. having a PR not moving on for 20+ days (as you both mentioned, no WIP sign) worries me, from the review history of this one, I can only see some non-blocking nits.

I'm sorry for not checking the meeting notes for these.

[sftim]

SIG Docs discussed, in a meeting yesterday, that once there are a bunch of PRs that are ready to merge into the main branch, SIG Docs can help get those merged.

In my view, there great part of the effort is lining up PRs that are good to merge, and actually merging them is more restricted (needs an approver's time) but less effort.

We also agreed in that meeting that those involved favor continuing to work towards doing that merge after the v1.24 release.