Merge pull request #31636 from tengqm/fix-links-2
Fix links and markdown format for some pagespull/32070/head
Kubernetes Prow Robot
GitHub
commit
90188d33b7
|
|
@ -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:<namespace>` 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:<namespace>` group
|
||||
(where `<namespace>` 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
|
||||
`<root-dir>/seccomp` where `<root-dir>` 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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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 <<EOF > /tmp/pss/nginx-pod.yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: nginx
|
||||
spec:
|
||||
containers:
|
||||
- image: nginx
|
||||
name: nginx
|
||||
ports:
|
||||
- containerPort: 80
|
||||
EOF
|
||||
```
|
||||
```shell
|
||||
cat <<EOF > /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/)
|
||||
- [Apply Pod Security Standards at the cluster level](/docs/tutorials/security/cluster-level-pss/)
|
||||
|
|
|
|||
Loading…
Reference in New Issue