Projected томи

У цьому документі описано спроєцьовані томи в Kubernetes. Рекомендується ознайомитися з томами для кращого розуміння.

Вступ

Том projected відображає кілька наявних джерел томів в одну теку.

Зараз наступні типи джерел томів можуть бути спроєцьовані:

• secret
• downwardAPI
• configMap
• serviceAccountToken
• clusterTrustBundle
• podCertificate

Всі джерела повинні бути в тому ж просторі імен, що й Pod. Для отримання додаткових відомостей дивіться документ з дизайну все-в-одному томі.

Приклад конфігурації з secret, downwardAPI та configMap

pods/storage/projected-secret-downwardapi-configmap.yaml

apiVersion: v1
kind: Pod
metadata:
  name: volume-test
spec:
  containers:
  - name: container-test
    image: busybox:1.28
    command: ["sleep", "3600"]
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
  volumes:
  - name: all-in-one
    projected:
      sources:
      - secret:
          name: mysecret
          items:
            - key: username
              path: my-group/my-username
      - downwardAPI:
          items:
            - path: "labels"
              fieldRef:
                fieldPath: metadata.labels
            - path: "cpu_limit"
              resourceFieldRef:
                containerName: container-test
                resource: limits.cpu
      - configMap:
          name: myconfigmap
          items:
            - key: config
              path: my-group/my-config

Приклад конфігурації: secret з встановленим нестандартним режимом дозволу

pods/storage/projected-secrets-nondefault-permission-mode.yaml

apiVersion: v1
kind: Pod
metadata:
  name: volume-test
spec:
  containers:
  - name: container-test
    image: busybox:1.28
    command: ["sleep", "3600"]
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
  volumes:
  - name: all-in-one
    projected:
      sources:
      - secret:
          name: mysecret
          items:
            - key: username
              path: my-group/my-username
      - secret:
          name: mysecret2
          items:
            - key: password
              path: my-group/my-password
              mode: 511

Кожне спроєцьоване джерело тому перераховане в специфікації в розділі sources. Параметри майже такі ж, за винятком двох пунктів:

• Для секретів поле secretName було змінено на name, щоб бути послідовним з назвою ConfigMap.
• defaultMode можна вказати тільки на рівні спроєцьованого тому, а не для кожного джерела тому. Однак, як показано вище, ви можете явно встановити mode для кожної окремої проєкції.

Спроєцьовані томи serviceAccountToken

Ви можете впровадити токен для поточного service accountʼу в Pod за вказаним шляхом. Наприклад:

pods/storage/projected-service-account-token.yaml

apiVersion: v1
kind: Pod
metadata:
  name: sa-token-test
spec:
  containers:
  - name: container-test
    image: busybox:1.28
    command: ["sleep", "3600"]
    volumeMounts:
    - name: token-vol
      mountPath: "/service-account"
      readOnly: true
  serviceAccountName: default
  volumes:
  - name: token-vol
    projected:
      sources:
      - serviceAccountToken:
          audience: api
          expirationSeconds: 3600
          path: token

Pod в прикладі має project том, що містить впроваджений токен service account. Контейнери в цьому Pod можуть використовувати цей токен для доступу до сервера API Kubernetes, автентифікуючись за відомостями service accountʼу Pod. Поле audience містить призначену аудиторію токена. Отримувач токена повинен ідентифікувати себе за ідентифікатором, вказаним в аудиторії токена, інакше він повинен відхилити токен. Це поле є необовʼязковим, але стандартним для ідентифікації в API сервері.

Поле expirationSeconds містить час, через який токен стане недійсним. Типовим є час в одну годину, але він має бути принаймні 10 хвилин (600 секунд). Адміністратор може обмежити максимальне значення вказавши параметр --service-account-max-token-expiration в API сервері. Поле path містить відносний шлях до точки монтування тому.

Спроєцьовані томи clusterTrustBundle

Спроєцьований том clusterTrustBundle дозволяє впроваджувати контент одного чи більше обʼєктів ClusterTrustBundle як автоматично оновлюваний файл у файловій системі контейнера.

ClusterTrustBundle може бути обраний за допомогою name або signer name.

Для вибору за імʼям використовуйте поле name, щоб вказати один обʼєкт ClusterTrustBundle.

Для вибору за імʼям підписанта використовуйте поле signerName (і, за необхідності, поле labelSelector), щоб вказати набір обʼєктів ClusterTrustBundle, які використовують задане імʼя підписанта. Якщо labelSelector відсутнє, то вибираються всі ClusterTrustBundle для цього підписанта.

Kubelet виконує відсіювання дублікатів сертифікатів у вибраних обʼєктах ClusterTrustBundle, нормалізує представлення PEM (видаляючи коментарі та заголовки), перегруповує сертифікати та записує їх у файл, вказаний полем path. При зміні набору вибраних обʼєктів ClusterTrustBundle або їх вмісту kubelet підтримує актуальність файлу.

Типово kubelet запобігає запуску Podʼа, якщо заданий обʼєкт ClusterTrustBundle не знайдено, або якщо signerName / labelSelector не відповідає жодному обʼєкту ClusterTrustBundle. Якщо ця поведінка не відповідає вашим вимогам, встановіть поле optional в true, і Pod буде запущено з порожнім файлом за шляхом path.

pods/storage/projected-clustertrustbundle.yaml

apiVersion: v1
kind: Pod
metadata:
  name: sa-ctb-name-test
spec:
  containers:
  - name: container-test
    image: busybox
    command: ["sleep", "3600"]
    volumeMounts:
    - name: token-vol
      mountPath: "/root-certificates"
      readOnly: true
  serviceAccountName: default
  volumes:
  - name: token-vol
    projected:
      sources:
      - clusterTrustBundle:
          name: example
          path: example-roots.pem
      - clusterTrustBundle:
          signerName: "example.com/mysigner"
          labelSelector:
            matchLabels:
              version: live
          path: mysigner-roots.pem
          optional: true

Спроєцьовані томи podCertificate

Спроєцьовані томи podCertificate забезпечують безпечне надання приватного ключа та ланцюга сертифікатів X.509 для використання Podʼом як клієнтських, так і серверних облікових даних. Kubelet потім обробляє оновлення приватного ключа та ланцюга сертифікатів, коли вони наближаються до закінчення терміну дії. Застосунку просто потрібно переконатися, що він своєчасно перезавантажує файл, коли він змінюється, за допомогою механізму, такого як inotify або опитування.

Кожна проєкція podCertificate підтримує такі конфігураційні поля:

• signerName: підписувач, який ви хочете використовувати для видачі сертифіката. Зверніть увагу, що підписувачі можуть мати свої власні вимоги до доступу і можуть відмовитися видавати сертифікати вашому Podʼу.
• keyType: Тип приватного ключа, який повинен бути згенерований. Дійсні значення: ED25519, ECDSAP256, ECDSAP384, ECDSAP521, RSA3072 і RSA4096.
• maxExpirationSeconds: Максимальний термін дії, який ви приймете для сертифіката, виданого Podʼу. Якщо не вказано, стандартно це буде 86400 (24 години). Повинен бути не менше 3600 (1 година) і не більше 7862400 (91 день). Вбудовані підписувачі Kubernetes обмежені максимальним терміном дії 86400 (1 день). Підписувач має право видати сертифікат з терміном дії, коротшим за вказаний вами.
• credentialBundlePath: Відносний шлях у межах проєкції, куди має бути записаний пакет облікових даних. Пакет облікових даних — це файл у форматі PEM, де перший блок — це блок "PRIVATE KEY", що містить приватний ключ у форматі PKCS#8, а решта блоків — це блоки "CERTIFICATE", які складають ланцюг сертифікатів (сертифікат листа та будь-які проміжні сертифікати).
• keyPath і certificateChainPath: Окремі шляхи, куди Kubelet має записати тільки приватний ключ або ланцюг сертифікатів.

pods/storage/projected-podcertificate.yaml

# Приклад специфікації Pod, яка використовує проекцію podCertificate для запиту приватного ключа ED25519,
# сертифіката від підписувача `coolcert.example.com/foo` та
# запису результатів у `/var/run/my-x509-credentials/credentialbundle.pem`.
apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: podcertificate-pod
spec:
  serviceAccountName: default
  containers:
  - image: debian
    name: main
    command: ["sleep", "infinity"]
    volumeMounts:
    - name: my-x509-credentials
      mountPath: /var/run/my-x509-credentials
  volumes:
  - name: my-x509-credentials
    projected:
      defaultMode: 420
      sources:
      - podCertificate:
          keyType: ED25519
          signerName: coolcert.example.com/foo
          credentialBundlePath: credentialbundle.pem

Взаємодія SecurityContext

Пропозиція щодо обробки дозволів файлів у розширенні projected service account volume представляє, що projected файли мають відповідні набори дозволів власника.

Linux

У Podʼах Linux, які мають projected том та RunAsUser вказано у SecurityContext, projected файли мають правильно встановлені права власності, включаючи власника контейнера.

Коли у всіх контейнерах в Podʼі встановлено одне й те ж runAsUser у їх PodSecurityContext або SecurityContext, то kubelet гарантує, що вміст тому serviceAccountToken належить цьому користувачеві, а файл токена має режим дозволів, встановлений в 0600.

Windows

У Windows Podʼах, які мають projected том та RunAsUsername вказано в SecurityContext Podʼа, права власності не забезпечуються через спосіб управління користувачами у Windows. Windows зберігає та управляє локальними обліковими записами користувачів і груп у файлі бази даних, який називається Security Account Manager (SAM). Кожен контейнер підтримує свій власний екземпляр бази даних SAM, до якого хост не має доступу під час роботи контейнера. Контейнери Windows призначені для запуску режиму користувача операційної системи в ізоляції від хосту, тому не зберігають динамічну конфігурацію власності файлів хосту для облікових записів віртуалізованих контейнерів. Рекомендується розміщувати файли, які слід спільно використовувати з контейнером на машині-хості, в окремому змісті поза C:\.

Типово у projected файлах буде встановлено наступні права, як показано для прикладу projected файлу тома:

PS C:\> Get-Acl C:\var\run\secrets\kubernetes.io\serviceaccount\..2021_08_31_22_22_18.318230061\ca.crt | Format-List

Path   : Microsoft.PowerShell.Core\FileSystem::C:\var\run\secrets\kubernetes.io\serviceaccount\..2021_08_31_22_22_18.318230061\ca.crt
Owner  : BUILTIN\Administrators
Group  : NT AUTHORITY\SYSTEM
Access : NT AUTHORITY\SYSTEM Allow  FullControl
         BUILTIN\Administr

ators Allow  FullControl
         BUILTIN\Users Allow  ReadAndExecute, Synchronize
Audit  :
Sddl   : O:BAG:SYD:AI(A;ID;FA;;;SY)(A;ID;FA;;;BA)(A;ID;0x1200a9;;;BU)

Це означає, що всі адміністратори, такі як ContainerAdministrator, матимуть доступ на читання, запис та виконання, тоді як не-адміністратори матимуть доступ на читання та виконання.