Change:
`name` for the Pod. There's more about this in the [networking](/docs/concepts/cluster-administration/networking/) section. <del> ## Privileged mode for containers {{< note >}} Your {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}} must support the concept of a privileged container for this setting to be relevant. {{< /note >}} Any container in a pod can run in privileged mode to use operating system administrative capabilities that would otherwise be inaccessible. This is available for both Windows and Linux. ### Linux privileged containers In Linux, any container in a Pod can enable privileged mode using the `privileged` (Linux) flag on the [security context](/docs/tasks/configure-pod-container/security-context/) of the container spec. This is useful for containers that want to use operating system administrative capabilities such as manipulating the network stack or accessing hardware devices. ### Windows privileged containers {{< feature-state for_k8s_version="v1.26" state="stable" >}} In Windows, you can create a [Windows HostProcess pod](/docs/tasks/configure-pod-container/create-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. </del> <ins> ## Pod security settings {#pod-security} To set security constraints on Pods and containers, you use the `securityContext` field in the Pod specification. This field gives you granular control over what a Pod or individual containers can do. For example: * Drop specific Linux capabilities to avoid the impact of a CVE. * Force all processes in the Pod to run as a non-root user or as a specific user or group ID. * Set a specific seccomp profile. * Set Windows security options, such as whether containers run as HostProcess. {{< caution >}} You can also use the Pod securityContext to enable [_privileged mode_](/docs/concepts/security/linux-kernel-security-constraints/#privileged-containers) in Linux containers. Privileged mode overrides many of the other security settings in the securityContext. Avoid using this setting unless you can't grant the equivalent permissions by using other fields in the securityContext. In Kubernetes 1.26 and later, you can run Windows containers in a similarly privileged mode by setting the `windowsOptions.hostProcess` flag on the security context of the Pod spec. For details and instructions, see [Create a Windows HostProcess Pod](/docs/tasks/configure-pod-container/create-hostprocess-pod/). {{< /caution >}} * To learn about kernel-level security constraints that you can use, see [Linux kernel security constraints for Pods and containers](/docs/concepts/security/linux-kernel-security-constraints). * To learn more about the Pod security context, see [Configure a Security Context for a Pod or Container](/docs/tasks/configure-pod-container/security-context/). </ins> ## Static Pods

Discussion:
This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be The doesn't mention that you can run Pods with AppArmor / seccomp / whatever to constrain the container. Why is this needed Although we have tutorials that explain the concepts in the manner of a walkthough, having a concept guide is important too. It's OK if the mention within is more like a signpost: a hyperlink to another page such as (which doesn't exist). Comments /sig security Relevant to Relevant to
This should be a fun time Since we already talk about privileged mode on the Pods page I agree that it's important to talk about the security constraints that you can place on containers. I also agree that a standalone page that discusses container isolation strategies and kernel-level security measures would be a good addition to our docs. /triage accepted /assign
As a first step, I'll find out if this information exists across our current docs (it definitely does) and draft up a plan for changes.
The framing here should be: small simple soon
Thanks If you're willing to focus first on the minimum viable change that can allow seccomp and AppArmor to graduate with docs in place, that'll help. It does mean more overall work if you then revisit things to make a larger improvement. Sorry about that.
Going through the current content it feels disconnected talking about Privileged mode, without not mentioning isolation levels. For someone starting their learning journey it may be hard to understand what that really means. In my opinion, the existing section could become a higher level section about Security Context (or a brief point on isolation levels), and within there we could talk about the ways of constraining (or enforcing isolation of) the container execution via AppArmor, Seccomp, SELinux and Privileged containers. We probably should use this opportunity to highlight the impact of privileged mode on those constraints. wdyt?
Agreed that it's a bit out of place there.

We already have so I wonder how that fits... Regardless for the mvp for this issue I'll focus on a smaller scope to meet the requirements here and then we can fiddle and improve
Planned here: I'd appreciate reviews on the scope so that I can do a draft and get that reviewed
I drafted the MVP of that page: It's missing some info that I am not sure about
I'd be happy to see a PR anyway.
Still working on this, will send a PR soon
would you like any help here?
I'll open a draft PR in the coming days. One final ish question: The content in (the seccomp and Apparmor/SELinux sections) are a summary basically of the content in this new page. Think it's a good idea to remove that bulk from the checklist page and link to the new page to learn more?
I'd really like to hear your thoughts on Shannon's question in
Security has been one of the top concerns for a few years when people start evaluating k8s. What I'd like to see is a single concept page clearly outlining all relevant topics as links to more detailed references. In this concept page, we may want to articulate the shared-responsibility model where security topics are organized based on users' persona. In other words, as an application developer, what are the things I need to pay attention to? As a cluster operator, what are the best practices I need to check. As someone who prepares the underlying infrastructure, is there a checklist for me?
If merges first, we could build on that. Thoughts there?
I agree - we can expand that page or work it into a more use case based signposting topic. Some considerations though: We should think about how to organize it. There's the CNCF white paper phases, yes, but there's also the opportunity to organize by pillar, like authn/z, encryption, monitoring and logging, etc. Maybe a sensible combination of the two? The links we provide should be associated with specific jobs to be done. For example, in the Authorization pillar, we could have "Authorize actions in clusters" and list the learning journey (About authorization RBAC RBAC good practices RBAC how-to) Maybe we can create a follow-up issue for this and discuss the actual presentation of that information there?
Maybe we can draft a toc for this on google docs for discussion?

sounds good to me, we should probably also create a backlog issue for tracking purposes (I can do it later today I'm away from my computer still waking up )
Relevant to
We can now link from the Pod concept to