Автоматический выпуск SSL-сертификатов. Используем Kubernetes и FreeIPA

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

Важно! Чтобы воспользоваться этим способом выпуска SSL-сертификатов, у вас должны быть лишний кластер Kubernetes и FreeIPA, между которыми настроена сетевая связность. Если это так, поздравляю, летим за сертификатами.

Коротко о задаче

Сначала напомню, о чем вообще идет речь. Выпуск SSL-сертификатов для веб-ресурсов компании — типичная административная задача. Решать ее можно по-разному. Всегда есть вариант купить, цена вопроса — несколько десятков долларов. 

Также можно использовать бесплатные способы, в том числе основанные на алгоритмах протокола Automated Certificate Management Environment (ACME). Благодаря им можно заказать SSL-сертификат типа domain-validated. Это самый простой сертификат, который можно получить бесплатно на 90 дней. Дальше требуется обновление. 

Упростить работу с сертификатами можно с помощью Kubernetes. А точнее — благодаря плагину cert-manager. Его задача как раз сводится к тому, чтобы автоматизировать выпуск и обновление SSL-сертификатов. 

Сделать процесс еще проще, как выяснилось, позволяет сетевая связность Kubernetes с решениями IdM (от identity management, если вдруг забыли). В моем случае это FreeIPA. 

Плюсы способа:

• выпуск SSL-сертификата занимает максимум 5 минут (если делать все вручную, то можно зависнуть с задачей на полдня),

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

• все обновления происходят автоматически, не нужно просматривать сертификаты, отслеживать статусы по ним и т.д.

Переходим к делу

1. Для начала необходимо включить поддержку ACME во FreeIPA:

(idm)# ipa-acme-manage enable

2. Чтобы cert-manager добавил DNS-запись _acme-challenge во FreeIPA, используем провайдера cert-manager (в моем случае RFC-2136). Для этого мы должны создать новый ключ TSIG на нашем IPA-сервере:

tsig-keygen -a hmac-sha512 acme-update >> /etc/named/ipa-ext.conf

3. Далее необходимо подключить cert-manager к Kubernetes. Выполняется это действие следующей командой:

helm install \
  cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --version v1.14.4 \

4. Как только у нас появятся все необходимые манифесты, нужно будет создать секрет в Kubernetes для ключа TSIG. Для этого берем ключ TSIG и создаем с его помощью секрет Kubernetes:

kubectl -n cert-manager create secret generic ipa-tsig-secret --from-literal=tsig-secret-key="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"

На этом этапе заканчиваются основные настройки Kubernetes. При выпуске следующего сертификата начинаем с п. 5. 

5. Формируем ряд манифестов.

Переходим к ресурсу ClusterIssuer, который предоставляет сертификаты TLS. В нем указываем наш сервер IdM и зону, внутри которой мы будем выпускать сертификаты:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: myservice.testzone.nubes.ru
spec:
  acme:
    email: [e-mail]
    server: https://idm1.testzone.nubes.ru/acme/directory
    privateKeySecretRef:
      name: ipa-issuer-account-key
    solvers:
      - dns01:
          rfc2136:
            nameserver: idm.testzone.nubes.ru
            tsigKeyName: acme-update
            tsigAlgorithm: HMACSHA512
            tsigSecretSecretRef:
              name: ipa-tsig-secret
              key: tsig-secret-key
        selector:
          dnsZones:
            - 'testzone.nubes.ru'

7. Далее создаем NetworkPolicy.

NetworkPolicy представляет собой механизм управления сетевыми политиками. Он предназначен для определения правил доступа для сетевого трафика между подами в кластере. 

С помощью NetworkPolicy мы указываем нужные хуки в белые списки:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  annotations:
  name: myservice-acme-http-solver
  namespace: testzone
spec:
  ingress:
  - {}
  podSelector:
    matchExpressions:
    - key: acme.cert-manager.io/http-domain
      operator: Exists
    - key: acme.cert-manager.io/http-token
      operator: Exists
  policyTypes:
  - Ingress

8. В сертификате указываем, к какому ClusterIssuer будем обращаться и на какой адрес хотим выпустить сертификат. Также прописываем secretName (это нам понадобится для последнего манифеста):

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: myservice-cert
  namespace: testzone
spec:
  commonName: 'myservice.testzone.nubes.ru'
  dnsNames:
    - myservice.testzone.nubes.ru
  issuerRef:
    name: myservice.testzone.nubes.ru
    kind: ClusterIssuer
  privateKey:
    algorithm: RSA
    encoding: PKCS1
    size: 4096
  secretName: myservice-tls

9. И, собственно, последний из манифестов представляет собой Ingress. Указываем аннотацию 'kubernetes.io/tls-acme: "true"' и наш secretName:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    cert-manager.io/cluster-issuer: myservice.testzone.nubes.ru
    kubernetes.io/tls-acme: "true"
  name: myservice-ingress
  namespace: testzone
spec:
  ingressClassName: nginx
  rules:
  - host: myservice.testzone.nubes.ru
    http:
      paths:
      - backend:
          service:
            name: myservice-service
            port:
              number: 8080
        path: /
        pathType: Prefix
  tls:
  - hosts:
    - myservice.testzone.nubes.ru
    secretName: myservice-tls

10. На стороне IdM получаем:

А в Kubernetes видим:

kubectl -n testzone describe certificaterequests.cert-manager.io
...
...
...
  Conditions:
    Last Transition Time:  2024-04-17T12:19:01Z
    Message:               Certificate request has been approved by cert-manager.io
    Reason:                cert-manager.io
    Status:                True
    Type:                  Approved
    Last Transition Time:  2024-04-17T12:20:03Z
    Message:               Certificate fetched from issuer successfully
    Reason:                Issued
    Status:                True
    Type:                  Ready

Все, сертификат выпущен. В целом, конечно, можно заморочиться и делать все через Helm, и так даже правильнее. Но это уже совсем другая история…