Шифрование в Kubernetes: основы18.04.2024 12:46

Привет, Хабр!

Многие приложения работающие в Kubernetes обрабатывают конфиденциальную информацию, требующую защиты от несанкционированного доступа. Kubernetes предлагает удобные способы для защиты данных. Рассмотрим основные из них в этой статье, а именно — шифрование в покое, шифрование в передаче и зашифрованные томы в Pods.

Шифрование в покое

Шифрование данных в покое позволяет защитить данные, находящиеся в etcd, где Kubernetes хранит всю информацию о состоянии объектов, таких как Secrets и ConfigMaps.

Для включения шифрования данных в покое необходимо юзать файл конфигурации --encryption-provider-config, указывающий на спецификацию конфигурации шифрования. В этой конфигурации задаются поставщики шифрования, которые определяют, каким образом будут зашифрованы данные.

Пример элементарной конфигурации для шифрования объектов типа Secrets и ConfigMaps:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
      - configmaps
    providers:
      - aesgcm:
          keys:
            - name: key1
              secret: c2VjcmV0IGlzIHNlY3VyZQ==
            - name: key2
              secret: dGhpcyBpcyBwYXNzd29yZA==
      - identity: {}

В этом конфиге юзаем AES-GCM для шифрования, где secret является закодированным в base64 ключом. Провайдер identity указывается для обработки объектов без шифрования.

Для прокачки безопасности Kubernetes позволяет интегрировать внешние KMS для управления ключами шифрования. С версии Kubernetes 1.10 введена поддержка KMS провайдеров, которая позволяет API серверу отправлять ключи шифрования в KMS для их безопасного хранения и управления.

Схема работы с KMS предполагает использование оболочечного шифрования, при котором данные шифруются локально с помощью ключа шифрования данных, который, в свою очередь, шифруется с использованием ключа шифрования ключей, управляемого в KMS.

Для конфигурации KMS провайдера необходимо добавить его в файл конфигурации шифрования API сервера. Пример конфигурации с KMS провайдером:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - kms:
          name: myKMSProvider
          endpoint: unix:///var/run/kms-plugin/socket.sock
          cachesize: 100
          timeout: 3s

endpoint указывает на UNIX сокет, через который API сервер будет общаться с KMS плагином. cachesize определяет количество ключей шифрования данных, которые будут кэшироваться для ускорения процесса шифрования/дешифрования.

С версии Kubernetes 1.28 началась поддержка KMS v2, которая предлагает лучшие характеристики производительности и улучшенное управление ключами по сравнению с KMS v1. В KMS v2 сервер API использует функцию выработки ключей для генерации одноразовых ключей шифрования данных из секретного семени в сочетании с некоторыми случайными данными. Семя вращается при каждой смене ключа шифрования ключей.

Шифрование в передаче

Шифрование данных в передаче относится к защите информации, которая перемещается между компонентами системы или между системой и её пользователями. В Kubernetes это включает в себя шифрование трафика между нодами, а также между клиентами и API-сервером. Подобная защита данных часто достигается за счёт TLS.

В Kubernetes предоставляется API certificates.k8s.io, который позволяет генерировать TLS сертификаты, подписанные управляемым CA. Эти сертификаты и CA могут быть использованы рабочими нагрузками для установления доверия.

Для того чтобы начать использовать TLS в кластере, необходимо сначала сгенерировать ключи и сертификаты. Существует полно инструментов, наши любимые — cfssl и mkcert. Например, с помощью cfssl можно создать частный ключ и запрос на подпись сертификата, который затем может быть отправлен в Kubernetes API для создания объекта CertificateSigningRequest.

Пример создания CSR с использованием cfssl:

cat <

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo-payment-app-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
spec:
  tls:
  - hosts:
    - my-demo-app.local
    secretName: my-demo-app-tls
  rules:
  - host: my-demo-app.local
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: demo-payment-app
            port:
              number: 80

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: registry.k8s.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /my-nfs-data
      name: test-volume
  volumes:
  - name: test-volume
    nfs:
      server: my-nfs-server.example.com
      path: /my-nfs-volume
      readOnly: true