kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #31201 from mtilson/patch-3 

Remove extra command and fix reference to profile
pull/31219/head
Kubernetes Prow Robot 2022-01-05 13:17:48 -08:00 committed by GitHub
parent 1b75c44306 5e964818e8
commit 1bc24bb348
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 3 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
content/en/docs/tutorials/clusters/seccomp.md
View File

@ -342,17 +342,16 @@ syscalls. Here seccomp has been instructed to error on any syscall by setting
ability to do anything meaningful. What you really want is to give workloads ability to do anything meaningful. What you really want is to give workloads
only the privileges they need. only the privileges they need.
Clean up that Pod and Service before moving to the next section: Clean up that Pod before moving to the next section:
```shell ```shell
kubectl delete service violation-pod --wait
kubectl delete pod violation-pod --wait --now kubectl delete pod violation-pod --wait --now
``` ```
## Create Pod with seccomp profile that only allows necessary syscalls ## Create Pod with seccomp profile that only allows necessary syscalls
If you take a look at the `fine-pod.json`, you will notice some of the syscalls If you take a look at the `fine-grained.json` profile, you will notice some of the syscalls
seen in the first example where the profile set `"defaultAction": seen in syslog of the first example where the profile set `"defaultAction":
"SCMP_ACT_LOG"`. Now the profile is setting `"defaultAction": "SCMP_ACT_ERRNO"`, "SCMP_ACT_LOG"`. Now the profile is setting `"defaultAction": "SCMP_ACT_ERRNO"`,
but explicitly allowing a set of syscalls in the `"action": "SCMP_ACT_ALLOW"` but explicitly allowing a set of syscalls in the `"action": "SCMP_ACT_ALLOW"`
block. Ideally, the container will run successfully and you will see no messages block. Ideally, the container will run successfully and you will see no messages