Почему Kubernetes Vault ClusterIssuer повторно использует/выдает отмененный сертификат?

Вопрос или проблема

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: vault-cluster-issuer
  namespace: cert-manager
spec:
  vault:
    path: pki/sign/my-issuer
    server: http://vault.vault.svc.cluster.local:8200
    auth:
      kubernetes:
        role: cert-manager
        mountPath: /v1/auth/kubernetes
        secretRef:
          name: issuer-token
          key: token

Ответ или решение

Почему ClusterIssuer Kubernetes с использованием Vault повторно использует/выдает отозванный сертификат?

Ситуация, с которой вы столкнулись, действительно интересна и требует детального анализа работы компонентов, взаимодействующих между собой, а также понимания механизма управления сертификатами в Kubernetes и HashiCorp Vault.

Описание проблемы

Вы создали ClusterIssuer в Kubernetes, который корректно работает с Vault для выдачи сертификатов. Однако, после отзыва сертификата в Vault и удаления его из Kubernetes, ClusterIssuer всё равно восстанавливает сертификат, игнорируя статус его отзыва. Ваша ключевая озабоченность заключается в следующем:

• Почему отозванный сертификат повторно используется?
• Действительно ли ClusterIssuer запрашивает информацию из Vault по каждому запросу?
• Могут ли существовать механизмы кэширования в Kubernetes, предотвращающие обращение к Vault?

Интересные аспекты работы ClusterIssuer и Vault

1. Кэширование сертификатов: ClusterIssuer может хранить информацию о выданных сертификатах, включая их срок действия, а также статус. Если сертификат был выдан, и его срок действия не истек, ClusterIssuer может использовать его, вместо того чтобы запрашивать новый. Этот механизм кэширования позволяет уменьшить нагрузку на внешние системы.

2. Поведение Vault при отзывах: После отзыва сертификата в Vault его статус меняется, однако существующий сертификат может оставаться действительным в Kubernetes до истечения срока его действия или его удаления. Vault не пересылает автоматически статус отозванного сертификата на каждый запрос, если он не запрашивается явно.

3. Отсутствие проверки статуса сертификата: Когда ClusterIssuer запрашивает сертификат, он может не проверять статус существующего сертификата в Vault. Это приводит к ситуации, когда, даже если сертификат был отозван, ClusterIssuer повторно использует его, поскольку Kubernetes считает его действительным и "в актуальном состоянии".

4. Функция CRL: Как вы заметили, добавление списка отзывов сертификатов (CRL) в секрет ClusterIssuer позволяет ему корректно идентифицировать отозванные сертификаты. Это служит важным инструментом для поддержки актуальности и безопасности сертификатов. Включение CRL является рекомендованной практикой, позволяющей ClusterIssuer защититься от повторного использования отозванных сертификатов.

Рекомендации

Для избежания подобных ситуаций и улучшения управления сертификатами, рекомендуется:

• Включить CRL: Это обеспечит проверку статуса сертификатов во время их использования и предотвратит повторное использование отозванных сертификатов.

• Регулярно обновлять Kubernetes: Убедитесь, что используемая версия Kubernetes и cert-manager имеет последние исправления и обновления, так как улучшения и изменения в механизмах управления сертификатами могут повлиять на данное поведение.

• Мониторинг статуса: Настройте систему мониторинга и оповещений для отслеживания состояния сертификатов и их соответствия ожиданиям.

Заключение

Повторное использование отозванных сертификатов часто вызвано кэшированием коммунальных служб, недостаточной проверкой статуса сертификатов и отсутствием CRL. Применение CRL и правильные практики управления будут ключевыми для повышения безопасности вашей инфраструктуры.