cert-manager simplifica e automatiza o gerenciamento de certificados de segurança para o Kubernetes. O seguinte procedimento descreve como configurar o cert-manager para gerar certificados para recursos do MongoDB Kubernetes Operator.
Pré-requisitos
Para implementar um conjunto de réplicas usando um objeto, você deve:
Have or create an Ops Manager instance or a Cloud Manager organization.
Ter ou instalar os Controladores MongoDB para Kubernetes Operator.
Criar ou gerar um Kubernetes Operator ConfigMap.
Observação
Para evitar o armazenamento de segredos em sistemas do Kubernetes de cluster único, você pode migrar todos os segredos para uma ferramenta de armazenamento de segredos. As implantações em vários clusters do Kubernetes não suportam o armazenamento de segredos no armazenamento de segredos FERRAMENTAS, como o HashiCorp Vault.
Gere um certificado TLS para cada um dos seguintes componentes:
Seu conjunto de réplicas. Certifique-se de adicionar SANspara cada pod Kubernetes que hospeda um membro do seu conjunto de réplicas no certificado.
No certificado TLS , a SAN para cada pod deve usar o seguinte formato:
<pod-name>.<metadata.name>-svc.<namespace>.svc.cluster.local Importante
If you're using an ACME based service provider such as Let's Encrypt to issue TLS certificates, the provider might prohibit you from adding the Pod's default FQDNs (
*.svc.cluster.local) to SANs in the certificate.Para usar um certificado baseado em ACME, você deve configurar o certificado para o recurso do conjunto de réplicas. Para saber mais, consulte a etapa sobre certificados TLS baseados em ACME no procedimento.
O MongoDB Agent do seu projeto. Para o certificado do MongoDB Agent, certifique-se de atender aos seguintes requisitos:
O nome comum no certificado TLS não está vazio.
A Organização e a Unidade Organizacional combinadas em cada certificado TLS diferem da Organização e da Unidade Organizacional no certificado TLS para os membros do conjunto de réplicas.
Você deve ter o arquivo de certificado CA e nomeá-lo
ca-pem.Você deve ter a chave usada para assinar seus certificados TLS .
Importante
O operador Kubernetes usa kubernetes.io/tls segredos para armazenar certificados TLS e chaves privadas para o MongoDB Ops Manager e recursos do MongoDB. A partir da versão 1.17.0 do operador Kubernetes, ele não oferece suporte a arquivos PEM concatenados armazenados como Opaque secrets.
Para implementar um conjunto de réplicas usando um objeto, você deve:
Have or create an Ops Manager instance or a Cloud Manager organization.
Ter ou instalar os Controladores MongoDB para Kubernetes Operator.
Criar ou gerar um Kubernetes Operator ConfigMap.
Observação
Para evitar o armazenamento de segredos em sistemas do Kubernetes de cluster único, você pode migrar todos os segredos para uma ferramenta de armazenamento de segredos. As implantações em vários clusters do Kubernetes não suportam o armazenamento de segredos no armazenamento de segredos FERRAMENTAS, como o HashiCorp Vault.
Procedimento
Crie um segredo de CA.
Observação
As etapas a seguir pressupõem que você já criou uma CA personalizada, juntamente com a tls.key chave privada e o tls.crt certificado assinado correspondentes.
Crie um segredo para armazenar seus dados de CA :
apiVersion: v1 kind: Secret metadata: name: ca-key-pair namespace: <namespace> data: tls.crt: <your-CA-certificate> tls.key: <your-CA-private-key>
Adicione certificados adicionais aos certificados CA personalizados.
Se o MongoDB Ops Manager certificado TLS for assinado por uma CA personalizada , o certificado CA também deverá conter certificados adicionais que permitam MongoDB Ops Manager ao Backup Daemon do baixar MongoDB binários do da Internet. Para criar o(s) certificado(s)TLS , crie um ConfigMap para manter o certificado CA :
Importante
O Kubernetes Operator exige que seu certificado do Ops Manager seja denominado mms-ca.crt no ConfigMap.
Obtenha toda a cadeia de certificados TLS para o MongoDB Ops Manager de
downloads.mongodb.com. O seguinte comandoopensslgera o certificado na cadeia para o seu diretório de trabalho atual, no formato.crt:openssl s_client -showcerts -verify 2 \ -connect downloads.mongodb.com:443 -servername downloads.mongodb.com < /dev/null \ | awk '/BEGIN/,/END/{ if(/BEGIN/){a++}; out="cert"a".crt"; print >out}' Concatene o arquivo de certificado da sua CA para o MongoDB Ops Manager com a cadeia de certificados TLS completa de
downloads.mongodb.comque você obteve na etapa anterior:cat <custom_ca_cert.pem> cert2.crt cert3.crt cert4.crt >> mms-ca.crt Observação
Substitua o espaço reservado
<custom_ca_cert.pem>pelo seu arquivo PEM de certificado de CA personalizado.Não inclua seu arquivo
cert1.crt, pois é o certificado do servidor do MongoDB que não deve ser incluído.
Crie o ConfigMap para o Ops Manager:
kubectl create configmap om-http-cert-ca --from-file="mms-ca.crt"
Configurar um emissor de CA de gerenciamento seguro
Crie um emissor de CA que faça referência ao seu segredo de CA :
apiVersion: cert-manager.io/v1 kind: Issuer metadata: name: ca-issuer namespace: <namespace> spec: ca: secretName: ca-key-pair Verifique se o emissor está pronto:
kubectl get issuer ca-issuer O campo
READYna saída deve ter um valor deTrue.
Criar um CA ConfigMap
Crie um ConfigMap contendo sua CA. Deve ter dois campos, ca-pem e mms-ca.crt, ambos apontando para o seu certificado CA. Substitua <CA-certificate> pelo caminho do seu certificado CA.
kubectl create cm ca-issuer --from-file=ca-pem=<CA-certificate> \ --from-file=mms-ca.crt=<CA-certificate>
Criar certificados para seus recursos MongoDB
Para proteger um recurso do MongoDB com sua certificação gerada, você deve criar certificados para o próprio recurso e para o MongoDB Agent.
Crie o certificado de recurso MongoDB. O exemplo a seguir pressupõe um nome do conjunto
my-replica-setcom três membros:Observação
O parâmetro
spec.issuerRef.namefaz referência ao CA ConfigMap criado anteriormente.apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: my-replica-set-certificate namespace: mongodb spec: dnsNames: - my-replica-set-0 - my-replica-set-0.my-replica-set-svc.mongodb.svc.cluster.local - my-replica-set-1 - my-replica-set-1.my-replica-set-svc.mongodb.svc.cluster.local - my-replica-set-2 - my-replica-set-2.my-replica-set-svc.mongodb.svc.cluster.local duration: 240h0m0s issuerRef: name: ca-issuer renewBefore: 120h0m0s secretName: mdb-my-replica-set-cert usages: - server auth - client auth Para clusters fragmentados, você deve criar um certificado para cada StatefulSet. Para saber mais sobre configuração de cluster fragmentado, consulte Implementar um cluster fragmentado.
Criar o certificado do MongoDB Agent:
Observação
O parâmetro
spec.issuerRef.namefaz referência ao CA ConfigMap criado anteriormente.apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: agent-certs namespace: mongodb spec: commonName: automation dnsNames: - automation duration: 240h0m0s issuerRef: name: ca-issuer renewBefore: 120h0m0s secretName: mdb-my-replica-set-agent-certs usages: - digital signature - key encipherment - client auth subject: countries: - US localities: - NY organizationalUnits: - a-1635241837-m5yb81lfnrz organizations: - cluster.local-agent provinces: - NY Criar o recurso MongoDB:
Observação
Se você deixar o parâmetro
spec.security.tls.canão especificado, o padrão será{replica-set}-ca.apiVersion: mongodb.com/v1 kind: MongoDB metadata: name: my-replica-set namespace: mongodb spec: type: ReplicaSet members: 3 version: 8.0.0 opsManager: configMapRef: name: my-project credentials: my-credentials security: certsSecretPrefix: mdb authentication: enabled: true modes: - X509 tls: ca: ca-issuer enabled: true
Criar certificados para Ops Manager e AppDB com TLS
Para proteger um recurso do Ops Manager, você deve primeiro criar certificados para o Ops Manager e o AppDB e, em seguida, criar o recurso do Ops Manager.
Criar o certificado do Ops Manager:
Observação
O parâmetro
spec.issuerRef.namefaz referência ao CA ConfigMap criado anteriormente.apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: cert-for-ops-manager namespace: mongodb spec: dnsNames: - om-with-https-svc.mongodb.svc.cluster.local duration: 240h0m0s issuerRef: name: ca-issuer renewBefore: 120h0m0s secretName: mdb-om-with-https-cert usages: - server auth - client auth Criar o certificado AppDB:
Observação
O parâmetro
spec.issuerRef.namefaz referência ao CA ConfigMap criado anteriormente.apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: appdb-om-with-https-db-cert namespace: mongodb spec: dnsNames: - om-with-https-db-0 - om-with-https-db-0.om-with-https-db-svc.mongodb.svc.cluster.local - om-with-https-db-1 - om-with-https-db-1.om-with-https-db-svc.mongodb.svc.cluster.local - om-with-https-db-2 - om-with-https-db-2.om-with-https-db-svc.mongodb.svc.cluster.local duration: 240h0m0s issuerRef: name: ca-issuer renewBefore: 120h0m0s secretName: appdb-om-with-https-db-cert usages: - server auth - client auth Criar o recurso do Ops Manager:
apiVersion: mongodb.com/v1 kind: MongoDBOpsManager metadata: name: om-with-https namespace: mongodb spec: adminCredentials: ops-manager-admin-secret version: "8.0.0" applicationDatabase: members: 3 security: certsSecretPrefix: appdb tls: ca: ca-issuer version: 8.0.0-ubi8 replicas: 1 security: certsSecretPrefix: mdb tls: ca: ca-issuer
Renovando certificados
o certifique-manager atualizará os certificados nas seguintes circunstâncias:
O certificado expira de acordo com seus campos
spec.durationespec.renewBefore.Você exclui o segredo que contém um certificado. Nesse caso, o certificado-manager recria o segredo de acordo com a configuração em seu recurso personalizado de certificado.
Você altera a configuração do recurso personalizado do certificado. Nesse caso, o certificado-manager recria o segredo que contém o certificado quando detecta as alterações em sua configuração.