You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/en/docs/tasks/configure-pod-container/security-context.md
+54-39Lines changed: 54 additions & 39 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,21 +14,31 @@ A security context defines privilege and access control settings for
14
14
a Pod or Container. Security context settings include, but are not limited to:
15
15
16
16
* Discretionary Access Control: Permission to access an object, like a file, is based on
17
-
[user ID (UID) and group ID (GID)](https://wiki.archlinux.org/index.php/users_and_groups).
17
+
[user ID (UID) and group ID (GID)](https://wiki.archlinux.org/index.php/users_and_groups).
18
18
19
-
*[Security Enhanced Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux): Objects are assigned security labels.
19
+
*[Security Enhanced Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux):
20
+
Objects are assigned security labels.
20
21
21
22
* Running as privileged or unprivileged.
22
23
23
-
*[Linux Capabilities](https://linux-audit.com/linux-capabilities-hardening-linux-binaries-by-removing-setuid/): Give a process some privileges, but not all the privileges of the root user.
Give a process some privileges, but not all the privileges of the root user.
24
26
25
-
*[AppArmor](/docs/tutorials/clusters/apparmor/): Use program profiles to restrict the capabilities of individual programs.
27
+
*[AppArmor](/docs/tutorials/security/apparmor/):
28
+
Use program profiles to restrict the capabilities of individual programs.
26
29
27
-
*[Seccomp](/docs/tutorials/clusters/seccomp/): Filter a process's system calls.
30
+
*[Seccomp](/docs/tutorials/security/seccomp/): Filter a process's system calls.
28
31
29
-
* AllowPrivilegeEscalation: Controls whether a process can gain more privileges than its parent process. This bool directly controls whether the [`no_new_privs`](https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt) flag gets set on the container process. AllowPrivilegeEscalation is true always when the container is: 1) run as Privileged OR 2) has `CAP_SYS_ADMIN`.
32
+
*`allowPrivilegeEscalation`: Controls whether a process can gain more privileges than
33
+
its parent process. This bool directly controls whether the
For more information about security mechanisms in Linux, see
38
48
[Overview of Linux Kernel Security Features](https://www.linux.com/learn/overview-linux-kernel-security-features)
39
49
40
-
41
-
42
50
## {{% heading "prerequisites" %}}
43
51
44
-
45
52
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
46
53
47
-
48
-
49
54
<!-- steps -->
50
55
51
56
## Set the security context for a Pod
@@ -91,7 +96,7 @@ ps
91
96
92
97
The output shows that the processes are running as user 1000, which is the value of `runAsUser`:
93
98
94
-
```shell
99
+
```none
95
100
PID USER TIME COMMAND
96
101
1 1000 0:00 sleep 1h
97
102
6 1000 0:00 sh
@@ -108,7 +113,7 @@ ls -l
108
113
The output shows that the `/data/demo` directory has group ID 2000, which is
109
114
the value of `fsGroup`.
110
115
111
-
```shell
116
+
```none
112
117
drwxrwsrwx 2 root 2000 4096 Jun 6 20:08 demo
113
118
```
114
119
@@ -127,19 +132,26 @@ ls -l
127
132
128
133
The output shows that `testfile` has group ID 2000, which is the value of `fsGroup`.
129
134
130
-
```shell
135
+
```none
131
136
-rw-r--r-- 1 1000 2000 6 Jun 6 20:08 testfile
132
137
```
133
138
134
139
Run the following command:
135
140
136
141
```shell
137
-
$ id
142
+
id
143
+
```
144
+
145
+
The output is similar to this:
146
+
147
+
```none
138
148
uid=1000 gid=3000 groups=2000
139
149
```
140
-
You will see that gid is 3000 which is same as `runAsGroup` field. If the `runAsGroup` was omitted the gid would
141
-
remain as 0(root) and the process will be able to interact with files that are owned by root(0) group and that have
142
-
the required group permissions for root(0) group.
150
+
151
+
From the output, you can see that `gid` is 3000 which is same as the `runAsGroup` field.
152
+
If the `runAsGroup` was omitted, the `gid` would remain as 0 (root) and the process will
153
+
be able to interact with files that are owned by the root(0) group and groups that have
154
+
the required group permissions for the root (0) group.
143
155
144
156
Exit your shell:
145
157
@@ -159,11 +171,14 @@ slowing Pod startup. You can use the `fsGroupChangePolicy` field inside a `secur
159
171
to control the way that Kubernetes checks and manages ownership and permissions
160
172
for a volume.
161
173
162
-
**fsGroupChangePolicy** - `fsGroupChangePolicy` defines behavior for changing ownership and permission of the volume
163
-
before being exposed inside a Pod. This field only applies to volume types that support
164
-
`fsGroup` controlled ownership and permissions. This field has two possible values:
174
+
**fsGroupChangePolicy** - `fsGroupChangePolicy` defines behavior for changing ownership
175
+
and permission of the volume before being exposed inside a Pod.
176
+
This field only applies to volume types that support `fsGroup` controlled ownership and permissions.
177
+
This field has two possible values:
165
178
166
-
*_OnRootMismatch_: Only change permissions and ownership if permission and ownership of root directory does not match with expected permissions of the volume. This could help shorten the time it takes to change ownership and permission of a volume.
179
+
*_OnRootMismatch_: Only change permissions and ownership if permission and ownership of
180
+
root directory does not match with expected permissions of the volume.
181
+
This could help shorten the time it takes to change ownership and permission of a volume.
167
182
*_Always_: Always change permission and ownership of the volume when volume is mounted.
168
183
169
184
For example:
@@ -176,7 +191,6 @@ securityContext:
176
191
fsGroupChangePolicy: "OnRootMismatch"
177
192
```
178
193
179
-
180
194
{{< note >}}
181
195
This field has no effect on ephemeral volume types such as
The output shows capabilities bitmap for the process:
356
370
357
-
```shell
371
+
```
358
372
...
359
373
CapPrm: 00000000aa0435fb
360
374
CapEff: 00000000aa0435fb
@@ -374,7 +388,10 @@ See [capability.h](https://github.com/torvalds/linux/blob/master/include/uapi/li
374
388
for definitions of the capability constants.
375
389
376
390
{{< note >}}
377
-
Linux capability constants have the form `CAP_XXX`. But when you list capabilities in your Container manifest, you must omit the `CAP_` portion of the constant. For example, to add `CAP_SYS_TIME`, include `SYS_TIME` in your list of capabilities.
391
+
Linux capability constants have the form `CAP_XXX`.
392
+
But when you list capabilities in your container manifest, you must
393
+
omit the `CAP_` portion of the constant.
394
+
For example, to add `CAP_SYS_TIME`, include `SYS_TIME` in your list of capabilities.
378
395
{{< /note >}}
379
396
380
397
## Set the Seccomp Profile for a Container
@@ -437,18 +454,19 @@ the Pod's Volumes when applicable. Specifically `fsGroup` and `seLinuxOptions` a
437
454
applied to Volumes as follows:
438
455
439
456
* `fsGroup`: Volumes that support ownership management are modified to be owned
440
-
and writable by the GID specified in `fsGroup`. See the
label given to all Containers in the Pod as well as the Volumes.
449
466
450
467
{{< warning >}}
451
-
After you specify an MCS label for a Pod, all Pods with the same label can access the Volume. If you need inter-Pod protection, you must assign a unique MCS label to each Pod.
468
+
After you specify an MCS label for a Pod, all Pods with the same label can access the Volume.
469
+
If you need inter-Pod protection, you must assign a unique MCS label to each Pod.
452
470
{{< /warning >}}
453
471
454
472
## Clean up
@@ -462,11 +480,8 @@ kubectl delete pod security-context-demo-3
0 commit comments