Skip to content

Commit 1f45c16

Browse files
lpettyjolpettyjo
authored
Merge pull request #49181 from kquinn1204/BZ-2010564
BZ-2010564 Creating initial submit - configuring seccomp profile
2 parents ae52808 + 993c06f commit 1f45c16

File tree

2 files changed

+110
-16
lines changed

2 files changed

+110
-16
lines changed

‎modules/configuring-default-seccomp-profile.adoc

Lines changed: 106 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -1,15 +1,111 @@
1-
[id="configuring-default-seccomp-profile_{context}"]
2-
= Configuring the default seccomp profile
3-
OpenShift ships with a default seccomp profile that is referenced as `runtime/default`. You can enable the default seccomp profile for a pod or container workload by setting `RuntimeDefault` as following:
1+
// Module included in the following assemblies:
2+
//
3+
// * security/seccomp-profiles.adoc
44

5-
.Example
5+
:_content-type: PROCEDURE
66

7-
[source, yaml]
7+
[id="verifying-default-seccomp-profile_{context}"]
8+
= Verifying the default seccomp profile applied to a pod
9+
10+
{product-title} ships with a default seccomp profile that is referenced as `runtime/default`. In {product-version}, newly created pods have the Security Context Constraint (SCC) set to `restricted-v2` and the default seccomp profile applies to the pod.
11+
12+
.Procedure
13+
14+
. You can verify the Security Context Constraint (SCC) and the default seccomp profile set on a pod by running the following commands:
15+
16+
.. Verify what pods are running in the namespace:
17+
+
18+
[source, terminal]
19+
----
20+
$ oc get pods -n <namespace>
21+
----
22+
+
23+
For example, to verify what pods are running in the `workshop` namespace run the following:
24+
+
25+
[source, terminal]
26+
----
27+
$ oc get pods -n workshop
28+
----
29+
+
30+
.Example output
31+
+
32+
[source, terminal]
33+
----
34+
NAME READY STATUS RESTARTS AGE
35+
parksmap-1-4xkwf 1/1 Running 0 2m17s
36+
parksmap-1-deploy 0/1 Completed 0 2m22s
37+
----
38+
+
39+
.. Inspect the pods:
40+
+
41+
[source, terminal]
42+
----
43+
$ oc get pod parksmap-1-4xkwf -n workshop -o yaml
44+
----
45+
+
46+
.Example output
47+
+
48+
[source, terminal]
49+
----
50+
apiVersion: v1
51+
kind: Pod
52+
metadata:
53+
annotations:
54+
k8s.v1.cni.cncf.io/network-status: |-
55+
[{
56+
"name": "openshift-sdn",
57+
"interface": "eth0",
58+
"ips": [
59+
"10.131.0.18"
60+
],
61+
"default": true,
62+
"dns": {}
63+
}]
64+
k8s.v1.cni.cncf.io/networks-status: |-
65+
[{
66+
"name": "openshift-sdn",
67+
"interface": "eth0",
68+
"ips": [
69+
"10.131.0.18"
70+
],
71+
"default": true,
72+
"dns": {}
73+
}]
74+
openshift.io/deployment-config.latest-version: "1"
75+
openshift.io/deployment-config.name: parksmap
76+
openshift.io/deployment.name: parksmap-1
77+
openshift.io/generated-by: OpenShiftWebConsole
78+
openshift.io/scc: restricted-v2 <1>
79+
seccomp.security.alpha.kubernetes.io/pod: runtime/default <2>
80+
----
81+
<1> The `restricted-v2` SCC is added by default if your workload does not have access to a different SCC.
82+
<2> Newly created pods in {product-version} will have the seccomp profile configured to `runtime/default` as mandated by the SCC.
83+
84+
[id="upgraded_cluster_{context}"]
85+
== Upgraded cluster
86+
87+
In clusters upgraded to {product-version} all authenticated users have access to the `restricted` and `restricted-v2` SCC.
88+
89+
A workload admitted by the SCC `restricted` for example, on a {product-title} v4.10 cluster when upgraded may get admitted by `restricted-v2`. This is because `restricted-v2` is the more restrictive SCC between `restricted` and `restricted-v2`.
90+
[NOTE]
91+
====
92+
The workload must be able to run with `retricted-v2`.
93+
====
94+
95+
Conversely with a workload that requires `privilegeEscalation: true` this workload will continue to have the `restricted` SCC available for any authenticated user. This is because `restricted-v2` does not allow `privilegeEscalation`.
96+
97+
[id="newly_installed_{context}"]
98+
== Newly installed cluster
99+
100+
For newly installed {product-title} v4.11 cluster, the `restricted-v2` replaces the `restricted` SCC as an SCC that is available to be used by any authenticated user. A workload with `privilegeEscalation: true`, is not admitted into the cluster since `restricted-v2` is the only SCC available for authenticated users by default.
101+
102+
The feature `privilegeEscalation` is allowed by `restricted` but not by `restricted-v2`. More features are denied by `restricted-v2` than were allowed by `restricted` SCC.
103+
104+
A workload with `privilegeEscalation: true` may be admitted into a newly installed {product-title} v4.11 cluster. To give access to the `restricted` SCC to the ServiceAccount running the workload (or any other SCC that can admit this workload) using a RoleBinding run the following command:
105+
106+
[source, terminal]
8107
----
9-
spec:
10-
securityContext:
11-
seccompProfile:
12-
type: RuntimeDefault
108+
$ oc -n <workload-namespace> adm policy add-scc-to-user <scc-name> -z <serviceaccount_name>
13109
----
14110

15-
Alternatively, you can use the pod annotations `seccomp.security.alpha.kubernetes.io/pod: runtime/default` and `container.seccomp.security.alpha.kubernetes.io/<container_name>: runtime/default`. However, this method is deprecated in {product-title} {product-version}.
111+
In {product-title} {product-version} the ability to add the pod annotations `seccomp.security.alpha.kubernetes.io/pod: runtime/default` and `container.seccomp.security.alpha.kubernetes.io/<container_name>: runtime/default` is deprecated.

‎security/seccomp-profiles.adoc

Lines changed: 4 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -7,13 +7,11 @@ include::_attributes/common-attributes.adoc[]
77
toc::[]
88

99
An {product-title} container or a pod runs a single application that performs one or more well-defined tasks. The application usually requires only a small subset of the underlying operating system kernel APIs.
10-
Seccomp, secure computing mode, is a Linux kernel feature that can be used to limit the process running in a container to only call a subset of the available system calls. These system calls can be configured by creating a profile that is applied to a container or pod.
11-
Seccomp profiles are stored as JSON files on the disk.
10+
Secure computing mode, seccomp, is a Linux kernel feature that can be used to limit the process running in a container to only using a subset of the available system calls.
1211

13-
[IMPORTANT]
14-
====
15-
OpenShift workloads run unconfined by default, without any seccomp profile applied.
16-
====
12+
The `restricted-v2` SCC applies to all newly created pods in {product-version}. The default seccomp profile `runtime/default` is applied to these pods.
13+
14+
Seccomp profiles are stored as JSON files on the disk.
1715

1816
[IMPORTANT]
1917
====

0 commit comments

Comments
 (0)