DaemonSet для kubernetes отлично работает в привилегированном режиме, но дает сбой, даже если добавлены все возможности Linux.

У меня есть Daemonset, работающий в привилегированном режиме в кластере kubernetes. Это спецификация YAML набора демонов.

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: my-daemon
spec:
  template:
    metadata:
      labels:
        app: my-daemon
    spec:
      hostNetwork: true
      serviceAccountName: my-sa-account
      containers:
      - name: my-daemon
        image: akhilerm/my-daemon:0.5
        imagePullPolicy: Always
        securityContext:
          privileged: true
...
...

Вместо использования privileged:true я перехожу к возможностям Linux для предоставления разрешений DaemonSet. Поэтому я добавил в контейнер все возможности линукса и удалил privileged:true. Это новая спецификация YAML

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: my-daemon
spec:
  template:
    metadata:
      labels:
        app: my-daemon
    spec:
      hostNetwork: true
      serviceAccountName: my-sa-account
      containers:
      - name: my-daemon
        image: akhilerm/my-daemon:0.5
        imagePullPolicy: Always
        securityContext:
          capabilities:
            add: ["NET_BROADCAST", "NET_ADMIN", ..all CAPs..,"SYS_ADMIN"]
...
...

Но при использовании с возможностями Linux демон ведет себя не так, как ожидалось. В обоих случаях битовая карта разрешений в /proc/1/status внутри контейнера одинакова.

...
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000010000
SigIgn: 0000000000000004
SigCgt: 0000000000014002
CapInh: 0000003fffffffff
CapPrm: 0000003fffffffff
CapEff: 0000003fffffffff
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
...

Есть ли еще какие-либо поля или разрешения, которые мне нужно установить при использовании возможностей Linux с модулем в kubernetes?


kubernetes daemonset linux-capabilities
person Akhil Mohan    schedule 03.02.2019    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Я не уверен на 100%, но проблема может заключаться в отсутствующем поле capabilities:.

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: my-daemon
spec:
  template:
    metadata:
      labels:
        app: my-daemon
    spec:
      hostNetwork: true
      serviceAccountName: my-sa-account
      containers:
      - name: my-daemon
        image: akhilerm/my-daemon:0.5
        imagePullPolicy: Always
        securityContext:
          capabilities:
            add: ["NET_BROADCAST", "NET_ADMIN", ..all CAPs..,"SYS_ADMIN"]
...
...

or

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: my-daemon
spec:
  template:
    metadata:
      labels:
        app: my-daemon
    spec:
      hostNetwork: true
      serviceAccountName: my-sa-account
      containers:
      - name: my-daemon
        image: akhilerm/my-daemon:0.5
        imagePullPolicy: Always
        securityContext:
          capabilities:
            add:
            - NET_BROADCAST
            - NET_ADMIN
            - ...
            - SYS_ADMIN
...
...

Проверьте это и дайте мне знать, если есть какие-либо успехи. Если нет - я постараюсь копнуть глубже и предоставить вам другое решение. Я нашел именно этот формат во всех примерах, так что надеюсь, что это поможет. В качестве реального примера я могу предоставить вам kubernetes-the-not-so-hard-way-with-ansible-ingress-with-traefik со следующими пояснениями:

securityContext:
  capabilities:
    drop:
    - ALL
    add:
    - NET_BIND_SERVICE

Без этой настройки мы не сможем привязать Traefik к портам 80 и 443 (что в принципе справедливо для всех сервисов, которые хотят использовать порты ‹ 1024). Мы также можем использовать привилегированный: правда, но это делает поверхность атаки намного больше. Таким образом, использование возможностей Linux дает нам детальный контроль над разрешениями суперпользователя и сводит их к минимуму.

Или еще 1 из официальной статьи Kubernetes security-context, но на этот раз конфигурация для Pod:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-4
spec:
  containers:
  - name: sec-ctx-4
    image: gcr.io/google-samples/node-hello:1.0
    securityContext:
      capabilities:
        add: ["NET_ADMIN", "SYS_TIME"]

Надеюсь, что это поможет вам.

person Vit    schedule 04.02.2019
comment
Поле Capabilities уже было, пропустил копирование-вставку. Обновил так же в вопросе. Я попробовал оба варианта, которые вы дали в ответе. Все еще никаких изменений. Кроме того, в привилегированном режиме каталог /dev имеет больше устройств, чем работает со всеми возможностями. - person Akhil Mohan; 05.02.2019