Configure the security context of a node
In addition to having the pod use the Linux namespace of the host node, you can configure other security-related features in the description of the pod or the container to which it belongs using the security Context side item. This option can be applied to the entire pod or to a separate container within each pod.
Understanding what can be configured in a security context allows you to do many things
- Specifies the user (user ID) who runs the process in the container.
- Prevent containers from running using the root user (the default running user of the container is usually specified in its image, so you may need to prevent the root user of the container from running
- Run the container in privileged mode with full access to the host node's kernel
- In contrast, configure fine-grained kernel access by adding or disabling kernel functionality.
- Set SELinux C Security aced Linux Security Enhanced Linux) side items to tighten container restrictions.
- Prevent processes from writing to the root file system of the container
The following will begin exploring the details of these side items
Run pod without configuring security context
First, run
Of which there is no security context configured
pod
(No security context options are specified),
With a security context configured
pod
Contrast:
$ kuhectl run pod-with-defaults --image alpine --restart Never -- /bin/sleep 999999 pod "pod-with defaults" created
Take a look at the users in this container
ID
And groups
ID
And the user groups to which it belongs
This can be achieved by
Run in Container
id
Command View
$ kuhectl exec pod-with-defaults id uid;Q(root) gid;Q(root) groups;Q(root), l(b n), 2 (daemon), 3 (sys) , 4 (adrn) , 6 (disk )，work (wheel), 11 (floppy), 20 (dialout), 26 (tape), 27 (v deo) [root@k8s-master ~]# kubectl get pod NAME READY STATUS RESTARTS AGE nginx-6799fc88d8-drb2s 1/1 Running 3 263d [root@k8s-master ~]# kubectl exec -it nginx-6799fc88d8-drb2s bash kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead. root@nginx-6799fc88d8-drb2s:/# id uid=0(root) gid=0(root) groups=0(root) root@nginx-6799fc88d8-drb2s:/#
This container is in user
ID
(uid
) is
With
Households, that is
root
, User Groups
ID
(gid
) is
(same as)
Sample is root
Run under user group
It also belongs to
Some of them
His user group.
Note: The user used by the container runtime specifies the Dockerfile in the mirror by using the USER command. If the command is omitted, the container will run using the root user.
Now run a usage specific
User Run Container's
pod.
Run container with specified user
For use
And
Different users in the mirror
ID
To run pod
Need
Set this
Pod security context. RunAsUser Options
You can use the following code
List to run one
Container running with guest user at a
lpine
User ID in Mirror
405
[root@k8s-master ~]# cat test.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-as-user-guest
spec:
containers:
- name: main
image: alpine
command: ["/bin/sleep","99999"]
securityContext:
runAsUser: 405Note: You need to specify a user ID, not a user name, id 405 guest user
Now you can run the id command in the pod as before to see how the runAsUser option works:
[root@k8s-master ~]# kubectl get pod NAME READY STATUS RESTARTS AGE pod-as-user-guest 1/1 Running 0 63s [root@k8s-master ~]# kubectl exec -it pod-as-user-guest sh kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead. / $ id uid=405(guest) gid=100(users)
The container runs under the guest user as required.
Prevent container from running as root user
If you don't care which user the container is running, just want to prevent it from running as root?
Suppose you have a deployed
pod
, which uses
In
Docke
file
Use
USER
The daemon command makes a mirror of the image in the
daemon
Run under user,
If an attacker gains access to the mirror repository and uploads
All tags are identical, in
What happens to mirrors running under the root user?
When Kubernetes's dispatcher runs the new instance of the pod, kubelet downloads an attacker's image and runs any code in it.
Although the container is essentially isolated from the host node, use
root
It is still a bad practice for users to run processes in containers.
For example, when the
When a directory is mounted in a container, if the processes in that container use root
User runs,
It has full access to the directory and does not have full access if run with a non-root user
To prevent the above attack scenarios, you can configure the container in the pod to run as a non-root user.
As shown in the code listing below: (
Prevent containers from running using root user
)
[root@k8s-master ~]# cat test.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-as-user-guest
spec:
containers:
- name: main
image: alpine
command: ["/bin/sleep","99999"]
securityContext:
runAsNonRoot: true
[root@k8s-master ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
pod-as-user-guest 0/1 CreateContainerConfigError 0 53s
Normal Pulling 8h (x5 over 8h) kubelet, k8s-node2 Pulling image "alpine"
Warning Failed 8h (x5 over 8h) kubelet, k8s-node2 Error: container has runAsNonRoot and image will run as root
Now, even if attackers tamper with the mirror, they can't make progress
The destruction of steps.