diff --git a/content/en/docs/concepts/policy/pod-security-policy.md b/content/en/docs/concepts/policy/pod-security-policy.md index ea16157fcb..a8e90040ed 100644 --- a/content/en/docs/concepts/policy/pod-security-policy.md +++ b/content/en/docs/concepts/policy/pod-security-policy.md @@ -27,7 +27,8 @@ updates. ## What is a Pod Security Policy? A _Pod Security Policy_ is a cluster-level resource that controls security -sensitive aspects of the pod specification. The [PodSecurityPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) objects +sensitive aspects of the pod specification. The +[PodSecurityPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) objects define a set of conditions that a pod must run with in order to be accepted into the system, as well as defaults for the related fields. They allow an administrator to control the following: @@ -54,10 +55,10 @@ administrator to control the following: ## Enabling Pod Security Policies -Pod security policy control is implemented as an optional [admission -controller](/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy). -PodSecurityPolicies are enforced by [enabling the admission -controller](/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in), +Pod security policy control is implemented as an optional +[admission controller](/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy). +PodSecurityPolicies are enforced by +[enabling the admission controller](/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in), but doing so without authorizing any policies **will prevent any pods from being created** in the cluster. @@ -69,9 +70,9 @@ controller. ## Authorizing Policies When a PodSecurityPolicy resource is created, it does nothing. In order to use -it, the requesting user or target pod's [service -account](/docs/tasks/configure-pod-container/configure-service-account/) must be -authorized to use the policy, by allowing the `use` verb on the policy. +it, the requesting user or target pod's +[service account](/docs/tasks/configure-pod-container/configure-service-account/) +must be authorized to use the policy, by allowing the `use` verb on the policy. Most Kubernetes pods are not created directly by users. Instead, they are typically created indirectly as part of a @@ -132,6 +133,7 @@ subjects: If a `RoleBinding` (not a `ClusterRoleBinding`) is used, it will only grant usage for pods being run in the same namespace as the binding. This can be paired with system groups to grant access to all pods run in the namespace: + ```yaml # Authorize all service accounts in a namespace: - kind: Group @@ -143,45 +145,47 @@ paired with system groups to grant access to all pods run in the namespace: name: system:authenticated ``` -For more examples of RBAC bindings, see [Role Binding -Examples](/docs/reference/access-authn-authz/rbac#role-binding-examples). -For a complete example of authorizing a PodSecurityPolicy, see -[below](#example). +For more examples of RBAC bindings, see +[RoleBinding examples](/docs/reference/access-authn-authz/rbac#role-binding-examples). +For a complete example of authorizing a PodSecurityPolicy, see [below](#example). ### Recommended Practice -PodSecurityPolicy is being replaced by a new, simplified `PodSecurity` {{< glossary_tooltip -text="admission controller" term_id="admission-controller" >}}. For more details on this change, see -[PodSecurityPolicy Deprecation: Past, Present, and -Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/). Follow these -guidelines to simplify migration from PodSecurityPolicy to the new admission controller: +PodSecurityPolicy is being replaced by a new, simplified `PodSecurity` +{{< glossary_tooltip text="admission controller" term_id="admission-controller" >}}. +For more details on this change, see +[PodSecurityPolicy Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/). +Follow these guidelines to simplify migration from PodSecurityPolicy to the +new admission controller: -1. Limit your PodSecurityPolicies to the policies defined by the [Pod Security Standards](/docs/concepts/security/pod-security-standards): - - {{< example file="policy/privileged-psp.yaml" >}}Privileged{{< /example >}} - - {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}} - - {{< example file="policy/restricted-psp.yaml" >}}Restricted{{< /example >}} +1. Limit your PodSecurityPolicies to the policies defined by the + [Pod Security Standards](/docs/concepts/security/pod-security-standards): -2. Only bind PSPs to entire namespaces, by using the `system:serviceaccounts:` group + - {{< example file="policy/privileged-psp.yaml" >}}Privileged{{< /example >}} + - {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}} + - {{< example file="policy/restricted-psp.yaml" >}}Restricted{{< /example >}} + +1. Only bind PSPs to entire namespaces, by using the `system:serviceaccounts:` group (where `` is the target namespace). For example: - ```yaml - apiVersion: rbac.authorization.k8s.io/v1 - # This cluster role binding allows all pods in the "development" namespace to use the baseline PSP. - kind: ClusterRoleBinding - metadata: - name: psp-baseline-namespaces - roleRef: - kind: ClusterRole - name: psp-baseline - apiGroup: rbac.authorization.k8s.io - subjects: - - kind: Group - name: system:serviceaccounts:development - apiGroup: rbac.authorization.k8s.io - - kind: Group - name: system:serviceaccounts:canary - apiGroup: rbac.authorization.k8s.io - ``` + ```yaml + apiVersion: rbac.authorization.k8s.io/v1 + # This cluster role binding allows all pods in the "development" namespace to use the baseline PSP. + kind: ClusterRoleBinding + metadata: + name: psp-baseline-namespaces + roleRef: + kind: ClusterRole + name: psp-baseline + apiGroup: rbac.authorization.k8s.io + subjects: + - kind: Group + name: system:serviceaccounts:development + apiGroup: rbac.authorization.k8s.io + - kind: Group + name: system:serviceaccounts:canary + apiGroup: rbac.authorization.k8s.io + ``` ### Troubleshooting @@ -217,8 +221,8 @@ only non-mutating PodSecurityPolicies are used to validate the pod. ## Example -_This example assumes you have a running cluster with the PodSecurityPolicy -admission controller enabled and you have cluster admin privileges._ +This example assumes you have a running cluster with the PodSecurityPolicy +admission controller enabled and you have cluster admin privileges. ### Set up @@ -364,12 +368,24 @@ Let's try that again, slightly differently: ```shell kubectl-user create deployment pause --image=k8s.gcr.io/pause +``` + +```none deployment "pause" created - +``` +```shell kubectl-user get pods -No resources found. +``` +``` +No resources found. +``` + +```shell kubectl-user get events | head -n 2 +``` + +``` LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON SOURCE MESSAGE 1m 2m 15 pause-7774d79b5 ReplicaSet Warning FailedCreate replicaset-controller Error creating: pods "pause-7774d79b5-" is forbidden: no providers available to validate pod request ``` @@ -390,6 +406,9 @@ is `default`: kubectl-admin create rolebinding default:psp:unprivileged \ --role=psp:unprivileged \ --serviceaccount=psp-example:default +``` + +```none rolebinding "default:psp:unprivileged" created ``` @@ -398,6 +417,9 @@ eventually succeed in creating the pod: ```shell kubectl-user get pods --watch +``` + +```none NAME READY STATUS RESTARTS AGE pause-7774d79b5-qrgcb 0/1 Pending 0 1s pause-7774d79b5-qrgcb 0/1 Pending 0 1s @@ -411,6 +433,9 @@ Delete the namespace to clean up most of the example resources: ```shell kubectl-admin delete ns psp-example +``` + +``` namespace "psp-example" deleted ``` @@ -419,6 +444,9 @@ up separately: ```shell kubectl-admin delete psp example +``` + +``` podsecuritypolicy "example" deleted ``` @@ -435,7 +463,8 @@ several security mechanisms. {{< codenew file="policy/restricted-psp.yaml" >}} -See [Pod Security Standards](/docs/concepts/security/pod-security-standards/#policy-instantiation) for more examples. +See [Pod Security Standards](/docs/concepts/security/pod-security-standards/#policy-instantiation) +for more examples. ## Policy Reference @@ -471,17 +500,17 @@ and `max`(inclusive). Defaults to no allowed host ports. **Volumes** - Provides a list of allowed volume types. The allowable values correspond to the volume sources that are defined when creating a volume. For the complete list of volume types, see [Types of -Volumes](/docs/concepts/storage/volumes/#types-of-volumes). Additionally, `*` -may be used to allow all volume types. +Volumes](/docs/concepts/storage/volumes/#types-of-volumes). Additionally, +`*` may be used to allow all volume types. The **recommended minimum set** of allowed volumes for new PSPs are: -- configMap -- downwardAPI -- emptyDir -- persistentVolumeClaim -- secret -- projected +- `configMap` +- `downwardAPI` +- `emptyDir` +- `persistentVolumeClaim` +- `secret` +- `projected` {{< warning >}} PodSecurityPolicy does not limit the types of `PersistentVolume` objects that @@ -493,10 +522,10 @@ should be granted permission to create `PersistentVolume` objects. **FSGroup** - Controls the supplemental group applied to some volumes. - *MustRunAs* - Requires at least one `range` to be specified. Uses the -minimum value of the first range as the default. Validates against all ranges. + minimum value of the first range as the default. Validates against all ranges. - *MayRunAs* - Requires at least one `range` to be specified. Allows -`FSGroups` to be left unset without providing a default. Validates against -all ranges if `FSGroups` is set. + `FSGroups` to be left unset without providing a default. Validates against + all ranges if `FSGroups` is set. - *RunAsAny* - No default provided. Allows any `fsGroup` ID to be specified. **AllowedHostPaths** - This specifies a list of host paths that are allowed @@ -515,7 +544,8 @@ For example: readOnly: true # only allow read-only mounts ``` -{{< warning >}}There are many ways a container with unrestricted access to the host +{{< warning >}} +There are many ways a container with unrestricted access to the host filesystem can escalate privileges, including reading data from other containers, and abusing the credentials of system services, such as Kubelet. @@ -556,33 +586,33 @@ spec: **RunAsUser** - Controls which user ID the containers are run with. - *MustRunAs* - Requires at least one `range` to be specified. Uses the -minimum value of the first range as the default. Validates against all ranges. + minimum value of the first range as the default. Validates against all ranges. - *MustRunAsNonRoot* - Requires that the pod be submitted with a non-zero -`runAsUser` or have the `USER` directive defined (using a numeric UID) in the -image. Pods which have specified neither `runAsNonRoot` nor `runAsUser` settings -will be mutated to set `runAsNonRoot=true`, thus requiring a defined non-zero -numeric `USER` directive in the container. No default provided. Setting -`allowPrivilegeEscalation=false` is strongly recommended with this strategy. + `runAsUser` or have the `USER` directive defined (using a numeric UID) in the + image. Pods which have specified neither `runAsNonRoot` nor `runAsUser` settings + will be mutated to set `runAsNonRoot=true`, thus requiring a defined non-zero + numeric `USER` directive in the container. No default provided. Setting + `allowPrivilegeEscalation=false` is strongly recommended with this strategy. - *RunAsAny* - No default provided. Allows any `runAsUser` to be specified. **RunAsGroup** - Controls which primary group ID the containers are run with. - *MustRunAs* - Requires at least one `range` to be specified. Uses the -minimum value of the first range as the default. Validates against all ranges. + minimum value of the first range as the default. Validates against all ranges. - *MayRunAs* - Does not require that RunAsGroup be specified. However, when RunAsGroup -is specified, they have to fall in the defined range. + is specified, they have to fall in the defined range. - *RunAsAny* - No default provided. Allows any `runAsGroup` to be specified. **SupplementalGroups** - Controls which group IDs containers add. - *MustRunAs* - Requires at least one `range` to be specified. Uses the -minimum value of the first range as the default. Validates against all ranges. + minimum value of the first range as the default. Validates against all ranges. - *MayRunAs* - Requires at least one `range` to be specified. Allows -`supplementalGroups` to be left unset without providing a default. -Validates against all ranges if `supplementalGroups` is set. + `supplementalGroups` to be left unset without providing a default. + Validates against all ranges if `supplementalGroups` is set. - *RunAsAny* - No default provided. Allows any `supplementalGroups` to be -specified. + specified. ### Privilege Escalation @@ -627,8 +657,8 @@ added. Capabilities listed in `RequiredDropCapabilities` must not be included in `AllowedCapabilities` or `DefaultAddCapabilities`. **DefaultAddCapabilities** - The capabilities which are added to containers by -default, in addition to the runtime defaults. See the [Docker -documentation](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities) +default, in addition to the runtime defaults. See the +[Docker documentation](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities) for the default list of capabilities when using the Docker runtime. ### SELinux @@ -655,16 +685,17 @@ denoted as the string `Unmasked`. ### AppArmor -Controlled via annotations on the PodSecurityPolicy. Refer to the [AppArmor -documentation](/docs/tutorials/clusters/apparmor/#podsecuritypolicy-annotations). +Controlled via annotations on the PodSecurityPolicy. Refer to the +[AppArmor documentation](/docs/tutorials/security/apparmor/#podsecuritypolicy-annotations). ### Seccomp As of Kubernetes v1.19, you can use the `seccompProfile` field in the -`securityContext` of Pods or containers to [control use of seccomp -profiles](/docs/tutorials/clusters/seccomp). In prior versions, seccomp was -controlled by adding annotations to a Pod. The same PodSecurityPolicies can be -used with either version to enforce how these fields or annotations are applied. +`securityContext` of Pods or containers to +[control use of seccomp profiles](/docs/tutorials/security/seccomp/). +In prior versions, seccomp was controlled by adding annotations to a Pod. The +same PodSecurityPolicies can be used with either version to enforce how these +fields or annotations are applied. **seccomp.security.alpha.kubernetes.io/defaultProfileName** - Annotation that specifies the default seccomp profile to apply to containers. Possible values @@ -681,10 +712,10 @@ are: flag is not defined, the default path will be used, which is `/seccomp` where `` is specified by the `--root-dir` flag. -{{< note >}} + {{< note >}} The `--seccomp-profile-root` flag is deprecated since Kubernetes v1.19. Users are encouraged to use the default path. -{{< /note >}} + {{< /note >}} **seccomp.security.alpha.kubernetes.io/allowedProfileNames** - Annotation that specifies which values are allowed for the pod seccomp annotations. Specified as @@ -696,18 +727,22 @@ default cannot be changed. By default, all safe sysctls are allowed. -- `forbiddenSysctls` - excludes specific sysctls. You can forbid a combination of safe and unsafe sysctls in the list. To forbid setting any sysctls, use `*` on its own. -- `allowedUnsafeSysctls` - allows specific sysctls that had been disallowed by the default list, so long as these are not listed in `forbiddenSysctls`. +- `forbiddenSysctls` - excludes specific sysctls. You can forbid a combination + of safe and unsafe sysctls in the list. To forbid setting any sysctls, use + `*` on its own. +- `allowedUnsafeSysctls` - allows specific sysctls that had been disallowed by + the default list, so long as these are not listed in `forbiddenSysctls`. -Refer to the [Sysctl documentation]( -/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy). +Refer to the [Sysctl documentation](/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy). ## {{% heading "whatsnext" %}} -- See [PodSecurityPolicy Deprecation: Past, Present, and - Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/) to learn about - the future of pod security policy. +- See [PodSecurityPolicy Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/) + to learn about the future of pod security policy. -- See [Pod Security Standards](/docs/concepts/security/pod-security-standards/) for policy recommendations. +- See [Pod Security Standards](/docs/concepts/security/pod-security-standards/) + for policy recommendations. + +- Refer to [PodSecurityPolicy reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) + for the API details. -- Refer to [Pod Security Policy Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) for the api details. diff --git a/content/en/docs/reference/using-api/deprecation-policy.md b/content/en/docs/reference/using-api/deprecation-policy.md index e1c378c4ac..49136e6773 100644 --- a/content/en/docs/reference/using-api/deprecation-policy.md +++ b/content/en/docs/reference/using-api/deprecation-policy.md @@ -85,7 +85,7 @@ might have to add an equivalent field or represent it as an annotation. * **Beta API versions must be supported for 9 months or 3 releases (whichever is longer) after deprecation** * **Alpha API versions may be removed in any release without prior deprecation notice** -This ensures beta API support covers the [maximum supported version skew of 2 releases](/docs/setup/release/version-skew-policy/). +This ensures beta API support covers the [maximum supported version skew of 2 releases](/releases/version-skew-policy/). {{< note >}} There are no current plans for a major version revision of Kubernetes that removes GA APIs. diff --git a/content/en/docs/tutorials/security/ns-level-pss.md b/content/en/docs/tutorials/security/ns-level-pss.md index 119c1411e7..4a20895df7 100644 --- a/content/en/docs/tutorials/security/ns-level-pss.md +++ b/content/en/docs/tutorials/security/ns-level-pss.md @@ -8,57 +8,63 @@ weight: 10 This tutorial applies only for new clusters. {{% /alert %}} -Pod Security admission (PSA) is enabled by default in v1.23 and later, as it [graduated -to beta](/blog/2021/12/09/pod-security-admission-beta/). Pod Security Admission +Pod Security admission (PSA) is enabled by default in v1.23 and later, as it +[graduated to beta](/blog/2021/12/09/pod-security-admission-beta/). Pod Security Admission is an admission controller that applies -[Pod Security Standards](docs/concepts/security/pod-security-standards/) +[Pod Security Standards](/docs/concepts/security/pod-security-standards/) when pods are created. In this tutorial, you will enforce the `baseline` Pod Security Standard, one namespace at a time. You can also apply Pod Security Standards to multiple namespaces at once at the cluster -level. For instructions, refer to [Apply Pod Security Standards at the cluster level](/docs/tutorials/security/cluster-level-pss). +level. For instructions, refer to +[Apply Pod Security Standards at the cluster level](/docs/tutorials/security/cluster-level-pss). + ## {{% heading "prerequisites" %}} Install the following on your workstation: - [KinD](https://kind.sigs.k8s.io/docs/user/quick-start/#installation) -- [kubectl](https://kubernetes.io/docs/tasks/tools/) +- [kubectl](/docs/tasks/tools/) ## Create cluster 1. Create a `KinD` cluster as follows: - ```shell - kind create cluster --name psa-ns-level --image kindest/node:v1.23.0 - ``` + ```shell + kind create cluster --name psa-ns-level --image kindest/node:v1.23.0 + ``` + The output is similar to this: - ``` - Creating cluster "psa-ns-level" ... - ✓ Ensuring node image (kindest/node:v1.23.0) đŸ–ŧ - ✓ Preparing nodes đŸ“Ļ - ✓ Writing configuration 📜 - ✓ Starting control-plane 🕹ī¸ - ✓ Installing CNI 🔌 - ✓ Installing StorageClass 💾 - Set kubectl context to "kind-psa-ns-level" - You can now use your cluster with: + + ``` + Creating cluster "psa-ns-level" ... + ✓ Ensuring node image (kindest/node:v1.23.0) đŸ–ŧ + ✓ Preparing nodes đŸ“Ļ + ✓ Writing configuration 📜 + ✓ Starting control-plane 🕹ī¸ + ✓ Installing CNI 🔌 + ✓ Installing StorageClass 💾 + Set kubectl context to "kind-psa-ns-level" + You can now use your cluster with: - kubectl cluster-info --context kind-psa-ns-level + kubectl cluster-info --context kind-psa-ns-level - Not sure what to do next? 😅 Check out https://kind.sigs.k8s.io/docs/user/quick-start/ - ``` + Not sure what to do next? 😅 Check out https://kind.sigs.k8s.io/docs/user/quick-start/ + ``` 1. Set the kubectl context to the new cluster: - ```shell - kubectl cluster-info --context kind-psa-ns-level - ``` + + ```shell + kubectl cluster-info --context kind-psa-ns-level + ``` The output is similar to this: - ``` - Kubernetes control plane is running at https://127.0.0.1:50996 - CoreDNS is running at https://127.0.0.1:50996/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy + + ``` + Kubernetes control plane is running at https://127.0.0.1:50996 + CoreDNS is running at https://127.0.0.1:50996/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy - To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. - ``` + To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. + ``` ## Create a namespace @@ -67,7 +73,9 @@ Create a new namespace called `example`: ```shell kubectl create ns example ``` + The output is similar to this: + ``` namespace/example created ``` @@ -78,63 +86,68 @@ namespace/example created built-in Pod Security Admission. In this step we will warn on baseline pod security standard as per the latest version (default value) - ```shell - kubectl label --overwrite ns example \ + ```shell + kubectl label --overwrite ns example \ pod-security.kubernetes.io/warn=baseline \ pod-security.kubernetes.io/warn-version=latest - ``` + ``` 2. Multiple pod security standards can be enabled on any namespace, using labels. Following command will `enforce` the `baseline` Pod Security Standard, but `warn` and `audit` for `restricted` Pod Security Standards as per the latest version (default value) - ``` - kubectl label --overwrite ns example \ - pod-security.kubernetes.io/enforce=baseline \ - pod-security.kubernetes.io/enforce-version=latest \ - pod-security.kubernetes.io/warn=restricted \ - pod-security.kubernetes.io/warn-version=latest \ - pod-security.kubernetes.io/audit=restricted \ - pod-security.kubernetes.io/audit-version=latest - ``` + ```shell + kubectl label --overwrite ns example \ + pod-security.kubernetes.io/enforce=baseline \ + pod-security.kubernetes.io/enforce-version=latest \ + pod-security.kubernetes.io/warn=restricted \ + pod-security.kubernetes.io/warn-version=latest \ + pod-security.kubernetes.io/audit=restricted \ + pod-security.kubernetes.io/audit-version=latest + ``` ## Verify the Pod Security Standards 1. Create a minimal pod in `example` namespace: - ```shell - cat < /tmp/pss/nginx-pod.yaml - apiVersion: v1 - kind: Pod - metadata: - name: nginx - spec: - containers: - - image: nginx - name: nginx - ports: - - containerPort: 80 - EOF - ``` + ```shell + cat < /tmp/pss/nginx-pod.yaml + apiVersion: v1 + kind: Pod + metadata: + name: nginx + spec: + containers: + - image: nginx + name: nginx + ports: + - containerPort: 80 + EOF + ``` + 1. Apply the pod spec to the cluster in `example` namespace: - ```shell - kubectl apply -n example -f /tmp/pss/nginx-pod.yaml - ``` + + ```shell + kubectl apply -n example -f /tmp/pss/nginx-pod.yaml + ``` The output is similar to this: - ``` - Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "nginx" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost") - pod/nginx created - ``` + + ``` + Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "nginx" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost") + pod/nginx created + ``` 1. Apply the pod spec to the cluster in `default` namespace: - ```shell - kubectl apply -n default -f /tmp/pss/nginx-pod.yaml - ``` + + ```shell + kubectl apply -n default -f /tmp/pss/nginx-pod.yaml + ``` Output is similar to this: - ``` - pod/nginx created - ``` + + ``` + pod/nginx created + ``` The Pod Security Standards were applied only to the `example` namespace. You could create the same Pod in the `default` namespace @@ -149,11 +162,13 @@ Run `kind delete cluster -name psa-ns-level` to delete the cluster created. - Run a [shell script](/examples/security/kind-with-namespace-level-baseline-pod-security.sh) to perform all the preceding steps all at once. + 1. Create KinD cluster 2. Create new namespace 3. Apply `baseline` Pod Security Standard in `enforce` mode while applying `restricted` Pod Security Standard also in `warn` and `audit` mode. 4. Create a new pod with the following pod security standards applied + - [Pod Security Admission](/docs/concepts/security/pod-security-admission/) - [Pod Security Standards](/docs/concepts/security/pod-security-standards/) -- [Apply Pod Security Standards at the cluster level](/docs/tutorials/security/cluster-level-pss/) \ No newline at end of file +- [Apply Pod Security Standards at the cluster level](/docs/tutorials/security/cluster-level-pss/)