Как посмотреть состояние сертификата?

How do I check the certificate status?

Как получить список сертификатов?

How do I get a list of certificates?

Какие виды сертификатов поддерживаются?

What types of certificates are supported?

На данный момент модуль устанавливает два ClusterIssuer’а:

• letsencrypt
• letsencrypt-staging

Currently, the module supports the following two ClusterIssuers:

• letsencrypt
• letsencrypt-staging

Работает ли старая аннотация tls-acme?

Does the legacy tls-acme annotation work?

Да, работает! Специальный компонент (cert-manager-ingress-shim) видит эти аннотации и на их основании автоматически создает ресурсы Certificate (в тех же namespace, что и Ingress-ресурсы с аннотациями).

Yes, it works! The dedicated component (cert-manager-ingress-shim) automatically creates Certificate resources based on these annotations (in the same namespaces as those of Ingress resources with annotations).

Важно! При использовании аннотации, Certificate создается “прилинкованным” к существующему Ingress-ресурсу, и для прохождения challenge НЕ создается отдельный Ingress, а вносятся дополнительные записи в существующий. Это означает, что если на основном Ingress’е настроена аутентификация или whitelist — ничего не выйдет. Лучше не использовать аннотацию и переходить на Certificate.

Важно! При переходе с аннотации на Certificate нужно удалить Certificate который был создан по аннотации. Иначе, по обоим Certificate будет обновляться один Secret и это может привести к достижению лимита запросов Let’s Encrypt.

Caution! The Certificate for a particular annotation is linked to the existing Ingress resource. The additional records are put into the existing Ingress resource instead of creating a separate one. Thus, the process will fail if authentication or whitelist is set for the primary Ingress. In this case, you shouldn’t use the annotation; use the Certificate instead.

Caution! If you switched to the Certificate instead of annotation, then you need to delete the annotation-based Certificate. Otherwise, the same Secret will be updated for both Certificates (this may lead to exceeding the Let’s Encrypt limits).

yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: kubernetes.io/tls-acme: “true” # вот она, аннотация! name: example-com namespace: default spec: ingressClassName: nginx rules:

• host: example.com http: paths:
• backend: service: name: site port: number: 80 path: / pathType: ImplementationSpecific
• host: www.example.com # дополнительный домен http: paths:
• backend: service: name: site port: number: 80 path: / pathType: ImplementationSpecific
• host: admin.example.com # еще один дополнительный домен http: paths:
• backend: service: name: site port: number: 80 path: / pathType: ImplementationSpecific tls:
• hosts:
• example.com
• www.example.com # дополнительный домен
• admin.example.com # еще один дополнительный домен secretName: example-com-tls # так будут называться и certificate и secret

yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: kubernetes.io/tls-acme: “true” # here is the annotation! name: example-com namespace: default spec: ingressClassName: nginx rules:

• host: example.com http: paths:
• backend: service: name: site port: number: 80 path: / pathType: ImplementationSpecific
• host: www.example.com # the additional domain http: paths:
• backend: service: name: site port: number: 80 path: / pathType: ImplementationSpecific
• host: admin.example.com # another additional domain http: paths:
• backend: service: name: site port: number: 80 path: / pathType: ImplementationSpecific tls:
• hosts:
• example.com
• www.example.com # the additional domain
• admin.example.com # another additional domain secretName: example-com-tls # the name of the certificate & secret

Ошибка: CAA record does not match issuer

The “CAA record does not match issuer” error

Если cert-manager не может заказать сертификаты с ошибкой:

Suppose cert-manager gets the following error when trying to provide a certificate:

То необходимо проверить CAA (Certificate Authority Authorization) DNS запись у домена, для которого заказывается сертификат. Если вы хотите использовать Let’s Encrypt сертификаты, то у домена должна быть CAA запись: issue "letsencrypt.org". Подробнее про CAA можно почитать тут и тут.

In this case, you have to check the CAA (Certificate Authority Authorization) DNS record of the domain for which the certificate is intended. For Let’s Encrypt certificates, the domain must have the issue "letsencrypt.org" CAA record. You can read more about CAA here and here.

Интеграция с Vault

Vault integration

Вы можете использовать данную инструкцию для выпуска сертификатов с помощью Vault.

You can use this manual for configuring certificate issuance using Vault.

После конфигурации PKI и включения авторизации в Kubernetes, вам нужно:

• Создать service account и скопировать ссылку на его секрет:

After configuring PKI and enabling Kubernetes authorization, you have to:

• Create a service account and copy its secret reference:

• Создать Issuer:

• Create an Issuer:

shell kubectl apply -f - «EOF apiVersion: cert-manager.io/v1 kind: Issuer metadata: name: vault-issuer namespace: default spec: vault: если Vault разворачивался по вышеуказанной инструкции, в это месте в инструкции опечатка server: http://vault.default.svc.cluster.local:8200 указывается на этапе конфигурации PKI path: pki/sign/example-dot-com auth: kubernetes: mountPath: /v1/auth/kubernetes role: issuer secretRef: name: $ISSUER_SECRET_REF key: token EOF

shell kubectl apply -f - «EOF apiVersion: cert-manager.io/v1 kind: Issuer metadata: name: vault-issuer namespace: default spec: vault: HashiCorp instruction has mistype here server: http://vault.default.svc.cluster.local:8200 path: pki/sign/example-dot-com # configure in pki setup step auth: kubernetes: mountPath: /v1/auth/kubernetes role: issuer secretRef: name: $ISSUER_SECRET_REF key: token EOF

• Создать ресурс Certificate, для получения TLS сертификата подписанного Vault CA:

• Create a Certificate resource, to get a TLS certificate, which is issued by Vault CA:

shell kubectl apply -f - «EOF apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: example-com namespace: default spec: secretName: example-com-tls issuerRef: name: vault-issuer домены указываются на этапе конфигурации PKI в Vault commonName: www.example.com dnsNames:

• www.example.com EOF

shell kubectl apply -f - «EOF apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: example-com namespace: default spec: secretName: example-com-tls issuerRef: name: vault-issuer domains are set on PKI setup commonName: www.example.com dnsNames:

• www.example.com EOF

Как защитить учетные данные cert-manager?

How to secure cert-manager credentials?

Если вы не хотите хранить учетные данные конфигурации Deckhouse (например, по соображениям безопасности), вы можете создать свой собственный ClusterIssuer / Issuer. Например, вы можете создать свой ClusterIssuer для сервиса route53 следующим образом:

• Создайте секрет с учетными данными:

If you don’t want to store credentials in the Deckhouse configuration (security reasons, for example), feel free to create your own ClusterIssuer / Issuer. For example, you can create your own ClusterIssuer for a route53 service in this way:

• Create a Secret with credentials:

• Создайте простой ClusterIssuer со ссылкой на этот секрет:

• Create a simple ClusterIssuer with reference to that secret:

• Закажите сертификаты как обычно, используя созданный ClusterIssuer:

• Order certificates as usual, using created ClusterIssuer: