Можно ли получить доступ к подключенному тому в Kubernetes из файловой системы host os

Question

Мой реальный вопрос: если секреты монтируются в виде томов в модулях - их можно прочитать, если кто-то получит root-доступ к операционной системе хоста.

Например, с помощью доступа к / var / lib / docker и детализациик объему.

Answer 1

Если у кого-то есть root-доступ к вашему хосту с контейнерами, он может делать практически все, что захочет ... Не забывайте, что модули - это просто группа контейнеров, которые на самом деле являются процессами с pids. Так, например, если у меня есть стручок под названием Sleeper:

kubectl get pods sleeper-546494588f-tx6pp -o wide
NAME                       READY   STATUS    RESTARTS   AGE   IP            NODE         NOMINATED NODE
sleeper-546494588f-tx6pp   1/1     Running   1          21h   10.200.1.14   k8s-node-2   <none>

работает на узле k8s-node-2. Имея root-доступ к этому узлу, я могу проверить, какой pid у этого модуля и его контейнеров (я использую containerd в качестве механизма контейнеров, но приведенные ниже пункты очень похожи для докера или любого другого механизма контейнеров):

[root@k8s-node-2 /]# crictl -r  unix:///var/run/containerd/containerd.sock pods -name sleeper-546494588f-tx6pp -q
ec27f502f4edd42b85a93503ea77b6062a3504cbb7ac6d696f44e2849135c24e
[root@k8s-node-2 /]# crictl -r  unix:///var/run/containerd/containerd.sock ps -p ec27f502f4edd42b85a93503ea77b6062a3504cbb7ac6d696f44e2849135c24e
CONTAINER ID        IMAGE               CREATED             STATE               NAME                ATTEMPT             POD ID
70ca6950de10b       8ac48589692a5       2 hours ago         Running             sleeper             1                   ec27f502f4edd
[root@k8s-node-2 /]# crictl -r  unix:///var/run/containerd/containerd.sock# inspect   70ca6950de10b | grep pid | head -n 1
    "pid": 24180,

И, наконец, с помощью этой информации (номер pid) я могу получить доступ к точке монтирования "/" этого процесса и проверить его содержимое, включая секреты:

[root@k8s-node-2 /]# ll  /proc/24180/root/var/run/secrets/kubernetes.io/serviceaccount/
total 0
lrwxrwxrwx. 1 root root 13 Nov 14 13:57 ca.crt -> ..data/ca.crt
lrwxrwxrwx. 1 root root 16 Nov 14 13:57 namespace -> ..data/namespace
lrwxrwxrwx. 1 root root 12 Nov 14 13:57 token -> ..data/token
[root@k8s-node-2 serviceaccount]# cat  /proc/24180/root/var/run/secrets/kubernetes.io/serviceaccount/namespace ; echo
default
[root@k8s-node-2 serviceaccount]# cat  /proc/24180/root/var/run/secrets/kubernetes.io/serviceaccount/token | cut -d'.' -f 1 | base64 -d ;echo 
{"alg":"RS256","kid":""}
[root@k8s-node-2 serviceaccount]# cat  /proc/24180/root/var/run/secrets/kubernetes.io/serviceaccount/token | cut -d'.' -f 2 | base64 -d 2>/dev/null  ;echo 
{"iss":"kubernetes/serviceaccount","kubernetes.io/serviceaccount/namespace":"default","kubernetes.io/serviceaccount/secret.name":"default-token-6sbz9","kubernetes.io/serviceaccount/service-account.name":"default","kubernetes.io/serviceaccount/service-account.uid":"42e7f596-e74e-11e8-af81-525400e6d25d","sub":"system:serviceaccount:default:default"}

Это одна из причин, по которой очень важно правильно защитить доступ к вашей инфраструктуре kubernetes.