Конфигурирование#

API security.synapse.sber#

Certificate#

Формирует: Администратор/ CD Инструменты

Потребляет: controller

Область видимости: namespace

Описание: ресурс представляет собой читаемое определение запроса на подпись сертификата. cert-manager использует эти входные данные для генерации закрытого ключа и ресурса CertificateRequest

Пример конфигурации:

Конфигурация пользовательского ресурса Certificate для генерации и последующей ротации серверного сертификата

apiVersion: security.synapse.sber/v1
kind: Certificate
metadata:
  name: server-cert
spec:
  privateKey:
    algorithm: RSA
    size: 4096
    encoding: PKCS1
  uris:
    - spiffe://cluster.local/ns/$APP_NS/sa/$APP_SA
  usages:
    - server auth
  dnsNames:
    - $APP_DNS
  duration: 48h
  commonName: $APP_CN
  issuerRef:
    kind: CusterIssuer
    name: ESBRootCa
  renewBefore: 24h
  secretName: ingress-tls

где:

• $APP_NAME — имя разворачиваемого компонента;

• $APP_DNS — доменное имя сервера компонента;

• $APP_NS — название Kubernetes Namespace, в котором разворачивается компонент;

• $APP_SA — название Kubernetes ServiceAccount, под которым запускается компонент;

• $APP_CN — название SSL Certificate Common Name.

CertificateRequest#

Формирует: controller

Потребляет: controller

Область видимости: namespace

Описание: используется для запроса сертификатов X.509. Ресурс содержит строку в кодировке Base64 запроса на подпись сертификата(CSR) в кодировке PEM, которая отправляется указанному в спецификации Подписанту(Issuer или ClusterIssuer). В случае успешной выдачи будет возвращен подписанный сертификат на основе CSR. CertificateRequests обычно потребляются и управляются контроллерами или другими системами и не должны использоваться администраторами и CD инструментами.

Пример создаваемой CertificateRequest

apiVersion: security.synapse.sber/v1
kind: CertificateRequest
metadata:
  annotations:
    cert-manager.io/certificate-name: server-cert
    cert-manager.io/certificate-revision: '1'
    cert-manager.io/private-key-secret-name: server-cert-25mmm
  name: server-cert-1
  namespace: cert-manager-demo-client
  ownerReferences:
    - apiVersion: cert-manager.io/v1
      blockOwnerDeletion: true
      controller: true
      kind: Certificate
      name: server-cert
      uid: 6bf1cf34-79ba-4332-8f86-cbd1f39dc164
  labels:
    app.kubernetes.io/managed-by: Helm
spec:
  duration: 48h0m0s
  extra:
    authentication.kubernetes.io/pod-name:
      - cert-manager-66c4d59644-t8w65
    authentication.kubernetes.io/pod-uid:
      - 5fbcc3f0-7f1a-4f7b-985c-c286fd0d0738
  groups:
    - 'system:serviceaccounts'
    - 'system:serviceaccounts:cert-manager'
    - 'system:authenticated'
  issuerRef:
    kind: ClusterIssuer
    name: my-ca-issuer
  request: SOME_BASE64_CSR
  uid: a2b85f03-095d-46c8-a1a5-0beee65ed10f
  usages:
    - client auth
  username: 'system:serviceaccount:cert-manager:cert-manager'
status:
  ca: SOME_BASE64_CA_CERT
  certificate: SOME_BASE64_CERT

В поле spec описывается спецификация создаваемого сертификата, CSR в формате BASE64, метаинформация о создании сертификата, а так же информации о подписанте для сертификата.

В поле status, в случае успешной подписи сертификата, в поля certificate и CA подставляются сам сертификат и цепочка доверия для него соответственно. Информация в полях certificate и CA хранится в формате base64.

Issuer#

Формирует: Администратор/ CD Инструменты

Потребляет: controller

Область видимости: namespace

Описание: это кастомный ресурс Kubernetes, представляющий центр сертификации (ЦС), который может генерировать подписанные сертификаты, подписывая запросы на подпись сертификатов(CSR). Для всех сертификатов создаваемых через кастомный ресурс CertificateRequest требуется указанный Issuer, который готов попытаться выполнить запрос. Данный ресурс можно использовать только в рамках namespace в котором он был объявлен

Примеры:

Самоподписанный Issuer: Данная функциональность используется, когда необходим самоподписанный сертификат (то есть подписанный своим же приватным ключом).

apiVersion: security.synapse.sber/v1
kind: Issuer
metadata:
  name: selfsigned
  namespace: example1
spec:
  selfSigned: {}

для последующего использования в Certificate

apiVersion: security.synapse.sber/v1
kind: Certificate
metadata:
  name: exemple-certificate
  namespace: example1
spec:
  secretName: example-certificate
  dnsNames:
    - example.example1
  issuerRef:
    name: selfsigned

Подпись с помощью секрета: Изначально есть некая ключевая пара, хранящаяся в Secret ca-key-pair, которой необходимо подписывать сертификаты.

apiVersion: v1
kind: Secret
metadata:
  name: ca-key-pair
  namespace: example2
data:
  tls.crt: SOME_CERT==
  tls.key: SOME_KEY==

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

apiVersion: security.synapse.sber/v1
kind: Issuer
metadata:
  name: ca-issuer
  namespace: example2
spec:
  ca:
    secretName: ca-key-pair

ClusterIssuer#

Формирует: Администратор/ CD Инструменты

Потребляет: controller

Область видимости: Cluster

Описание: представляет собой версию пользовательского ресурса Issuer, которая не привязана к NS и которую можно использовать во всем кластере

Примеры:

Самоподписанный ClusterIssuer: по аналогии с самоподписанным Issuer

apiVersion: security.synapse.sber/v1
kind: ClusterIssuer
metadata:
  name: selfsigned
spec:
  selfSigned: {}

apiVersion: security.synapse.sber/v1
kind: Certificate
metadata:
  name: exemple-certificate
  namespace: example1
spec:
  secretName: example-certificate
  dnsNames:
    - example.example1
  issuerRef:
    kind: ClusterIssuer
    name: selfsigned

Подпись с помощью ca: подпись с помощью ключевой пары.

Внимание! Секрет с ключевой парой должен храниться в том же NS, что и компонент KACM

apiVersion: v1
kind: Secret
metadata:
  name: ca-key-pair
  namespace: kacm-cert-manager
data:
  tls.crt: SOME_CERT==
  tls.key: SOME_KEY==

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

apiVersion: security.synapse.sber/v1
kind: ClusterIssuer
metadata:
  name: ca-issuer
spec:
  ca:
    secretName: ca-key-pair

Инъекция cabudle#

У компонента «Управление ключами и сертификатами» имеется функциональность, помогающая в конфигурировании полей cabunlde в ресурсах: Mutating Webhooks, Validating Webhooks Conversion Webhooks и API Services

В частности, компонент «Управление ключами и сертификатами» заполняет поле caBundle трех типов API: ValidatingWebhookConfiguration, MutatingWebhookConfiguration и APIService. Первые два типа ресурсов используются для настройки того, как сервер API Kubernetes подключается к webhook. Эти данные caBundle загружаются сервером API Kubernetes и используются для проверки сертификатов обслуживания webhook API. APIService используется для представления расширенного сервера API. CaBundle APIService может быть заполнено сертификатом CA, который можно использовать для проверки сертификата сервера API.

В дальнейшем эти три типа API будут упоминаться как «ресурсы для инъекций».

Ресурс для инъекции должен иметь одну из следующих аннотаций: security.synapse.sber/inject-ca-from или security.synapse.sber/inject-ca-from-secret в зависимости от источника инъекции. Подробные объяснения ниже.