Как смонтировать том HostPath в Kubernetes с помощью SELinux - PullRequest
Новая
       55

Как смонтировать том HostPath в Kubernetes с помощью SELinux

0 голосов
/ 23 июня 2018

Я пытаюсь смонтировать том hostPath в Pod Kubernetes. Ниже приведен пример спецификации тома hostPath, взятой из документации. Я выполняю развертывание на хостах, на которых запущен RHEL 7 с включенным SELinux. 

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:
      # directory location on host
      path: /data
      # this field is optional
      type: Directory

Когда мой Pod пытается прочитать из файла, который был смонтирован с базового хоста, я получаю ошибку «Permission Denied». Когда я запускаю setenforce 0, чтобы отключить SELinux, ошибка исчезает, и я могу получить доступ к файлу. Я получаю ту же ошибку при привязке монтирования каталога в контейнер Docker.

Проблема описана здесь и может быть исправлена ​​при использовании Docker с помощью флага z или Z bind mount, описанного в документации Docker здесь .

Пока я могу решить проблему, запустив 

chcon -Rt svirt_sandbox_file_t /path/to/my/host/dir/to/mount

Я вижу это как неприятный хак, поскольку мне нужно делать это на каждом хосте в моем кластере Kubernetes, а также потому, что мое развертывание Kubernetes, как описано в спецификации YAML, не является полным описанием того, что нужно сделано, чтобы мой YAML работал правильно. Отключение SELinux не вариант.

Я вижу, что Kubernetes упоминает контексты безопасности SELinux в документах здесь , но я не смог успешно смонтировать том hostPath в модуль без получения ошибки отказа в разрешении.

Как должен выглядеть YAML для успешного включения контейнера для монтирования тома HostPath с базового хоста, на котором выполняется SELinux?

Обновление:

Файл, к которому я обращаюсь, является сертификатом CA, который имеет следующие метки: 

system_u:object_r:cert_t:s0

Когда я использую следующие опции: 

securityContext:
  seLinuxOptions:
    level: "s0:c123,c456"

и затем проверьте ошибки аудита контроля доступа с помощью ausearch -m avc -ts recent, я вижу, что есть ошибка отказа в разрешении, когда контейнер имеет метку уровня s0:c123,c456, поэтому я вижу, что метка уровня работает. Я установил метку s0.

Однако, если я попытаюсь изменить метку type на cert_t, контейнер даже не запустится, возникает ошибка: 

container_linux.go:247: starting container process caused "process_linux.go:364: container init caused \"write /proc/self/task/1/attr/exec: invalid argument\""

Кажется, я не могу изменить типовой ярлык контейнера.

Ответы [ 3 ]

0 голосов
/ 25 июня 2018

Вы можете назначать метки SELinux, используя seLinuxOptions: 

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
    securityContext:
      seLinuxOptions:
        level: "s0:c123,c456"
  volumes:
  - name: test-volume
    hostPath:
      # directory location on host
      path: /data
      # this field is optional
      type: Directory

Согласно документации :

  • seLinuxOptions : Тома, поддерживающие маркировку SELinux, помечены как доступные для метки, указанной в seLinuxOptions. Обычно вам нужно только установить раздел уровня. Это устанавливает метку Multi-Category Security (MCS) , назначаемую всем контейнерам в модуле, а также томам .
0 голосов
/ 18 июля 2018

Я сталкиваюсь с подобной проблемой, и единственный обходной путь, который работал, добавляет "securityContext" с "privileged: true".

Дайте мне знать, если вы нашли решение.

0 голосов
/ 23 июня 2018

Вы можете попробовать с полными разрешениями: 

 ...
 image: k8s.gcr.io/test-webserver
 securityContext:
   privileged: true
 ...
...