Gerenciamento de certificados e segredos TLS e não TLS

Saiba como você pode usar certificados e segredos em seu cluster.

Considere usar Secrets Manager para gerenciar centralmente e atualizar automaticamente seus segredos.

Gerenciamento de certificados e segredos d TLS s com o Ingress

Seu certificado Ingress TLS é armazenado como um segredo Kubernetes. Para gerenciar os segredos do TLS no seu cluster, você pode usar o conjunto de comandos ibmcloud oc ingress secret .

Por exemplo, é possível importar um certificado de Secrets Manager para um segredo de Kubernetes em seu cluster executando o comando a seguir.

ibmcloud oc ingress secret create --cluster CLUSTER_NAME_OR_ID --cert-crn CRN --name SECRET_NAME --namespace openshift-ingress

Para importar o certificado com o ibmcloud oc ingress secret create comando, você deve ter uma instância Secrets Manager padrão registrada no seu cluster. Se você não tiver uma instância do Secrets Manager e seus segredos forem gravados diretamente no seu cluster, eles não terão o valor CRN necessário e você deverá copiá-los manualmente com os comandos do oc plug-in OpenShift.

Para visualizar todos os segredos do Ingress para certificados TLS em seu cluster, execute o comando a seguir.

ibmcloud oc ingress secret ls -c CLUSTER

Configuração dos segredos de TLS para o subdomínio Ingress fornecido por IBM

IBM fornece um subdomínio do Ingress e um certificado padrão TLS, armazenado como um segredo Kubernetes em seu cluster, que você pode especificar em seu recurso do Ingress. Os certificados do TLS fornecidos pela IBM são assinados por LetsEncrypt e são totalmente gerenciados pela IBM.

O curinga de subdomínio do Ingress fornecido pela IBM, *.<cluster_name>-<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloud, é registrado, por padrão, para o cluster. O certificado TLS fornecido pela IBM é um certificado curinga e pode ser usado para o subdomínio curinga.

Siga as etapas para usar o certificado padrão TLS para o subdomínio Ingress fornecido pelo IBM.

  1. Obtenha o nome da chave secreta onde o certificado TLS padrão está armazenado. Observe que esse é o nome secreto especificado na seção spec.tls de seu recurso do Ingress.

    ibmcloud oc cluster get -c CLUSTER | grep Ingress

    Saída de exemplo

    Ingress Subdomain:      mycluster-<hash>-0000.us-south.containers.appdomain.cloud
Ingress Secret:         mycluster-<hash>-0000

  2. Visualize os detalhes secretos e observe o valor do CRN. Esse é o CRN do certificado TLS. Se você não tiver uma instância padrão [Secrets Manager] registrada no seu cluster, seu segredo não tem um CRN. Consulte a nota na etapa a seguir para obter mais detalhes

    ibmcloud oc ingress secret get -c CLUSTER --name SECRET_NAME --namespace openshift-ingress

  3. Crie um segredo para o certificado padrão TLS em cada namespace em que existam seus recursos ou aplicativos do Ingress. Especifique o CRN do certificado TLS com a opção de comando --cert-crn.

    ibmcloud oc ingress secret create --cluster CLUSTER_NAME_OR_ID --cert-crn CRN --name SECRET_NAME --namespace openshift-ingress

    Para copiar o segredo com o ibmcloud oc ingress secret create comando, você deve ter uma instância Secrets Manager padrão registrada no seu cluster. Se você não tiver uma instância do Secrets Manager e seus segredos forem gravados diretamente no seu cluster, eles não terão o valor CRN necessário e você deverá copiá-los manualmente com os comandos do oc plug-in OpenShift.

Configuração dos segredos de TLS para subdomínios personalizados

Se você definir um subdomínio customizado em seu recurso do Ingress, será possível usar seu próprio certificado TLS para gerenciar o término do TLS. Você deve criar um segredo Kubernetes para armazenar o certificado TLS e, em seguida, importar esse segredo para cada namespace em que existam aplicativos.

Ao armazenar certificados TLS personalizados em Secrets Manager você pode importar seus certificados diretamente para um segredo Kubernetes em seu cluster.

  1. Crie ou importe um segredo para o certificado TLS no namespace em que o recurso do Ingress existe. Por exemplo, você pode importar um segredo de Secrets Manager para o seu cluster executando o seguinte comando. Especifique o CRN do certificado TLS com a opção de comando --cert-crn.

    Para importar o certificado com o ibmcloud oc ingress secret create comando, você deve ter uma instância Secrets Manager padrão registrada no seu cluster. Se você não tiver uma instância do Secrets Manager e seus segredos forem gravados diretamente no seu cluster, eles não terão o valor CRN necessário e você deverá copiá-los manualmente com os comandos do oc plug-in OpenShift.

    ibmcloud oc ingress secret create --name SECRET_NAME --cluster CLUSTER_NAME_OR_ID --cert-crn CERTIFICATE_CRN --namespace openshift-ingress

  2. Repita a etapa anterior para cada espaço de nomes onde seus apps existem.

Gerenciamento de segredos não relacionados ao TLS

Para gerenciar segredos não relacionados a TLS, você pode usar os comandos ibmcloud oc ingress secret.

Existem 5 tipos de segredos não relacionados ao TLS:

  • Segredos arbitrários segurar um valor string.
  • Credencias IAM realizar uma chave API IAM.
  • segredos de Username e senha guarde um nome de usuário e senha como dois valores separados.
  • Valores de chave detêm valores JSON.
  • As credenciais personalizadas contêm valores personalizados (string).

Saiba como você pode gerenciar de forma centralizada seus segredos não relacionados a TLS com IBM Cloud Secrets Manager. Com o Secrets Manager, você pode criar segredos gerenciados do Kubernetes, atualizar seus segredos automaticamente, criar grupos de segredos que controlam quem tem acesso aos segredos em seu cluster e muito mais.

Criação de um segredo não TLS em seu cluster

Crie um segredo que não seja TLS especificando a opção --type Opaque no comando ibmcloud oc ingress secret create comando. Com o tipo Opaque, você pode incluir vários valores de CRN não certificados. Se a opção --type não for especificada, o valor TLS será aplicado por padrão. Para obter mais informações e opções de comando adicionais, consulte a referência CLI.

O comando de exemplo a seguir cria um segredo não TLS com o tipo Opaque especificado. Os segredos que não sejam TLS exigem pelo menos um campo secreto. Note que como você especifica a opção --field varia com base no tipo de segredo que você cria.

ibmcloud oc ingress secret create -c cluster-test --name example-secret --namespace openshift-ingress --field crn:v1:bluemix:public:secrets-manager:us-south:a/1aa111aa1a11111aaa1a1111aa1aa111:111a1111-11a1 --type Opaque

Para verificar se o segredo é criado, liste todos os segredos no espaço de nomes.

kubectl get secret -n default

O exemplo a seguir mostra o resultado.

NAME                   TYPE                                  DATA   AGE
all-icr-io             kubernetes.io/dockerconfigjson        1      41h
default-token-8t6xw    kubernetes.io/service-account-token   3      41h
example-secret         Opaque                                        3m

Gerenciamento de campos secretos não TLS

Um campo secreto é um par de valores-chave que é armazenado em um segredo não TLS. Consulte os exemplos a seguir para visualizar, adicionar, atualizar ou remover campos secretos não relacionados a TLS.

Visualizando valores de campo

Você pode visualizar os valores de um campo de um segredo ao obter os detalhes do segredo.

kubectl get secret -n default example-secret -o yaml

A saída de exemplo a seguir mostra os campos secretos e seus valores na seção data.

apiVersion: v1
data:
  arbitraryFVT: AAAaaAAaAAA1AAAaaAAa
  userCredsFVT_password: aAAaa1aaaA=
  userCredsFVT_username: aAAaaa==
kind: Secret
metadata:
  annotations:
    ingress.cloud.ibm.com/cert-source: ibm
    razee.io/build-url: https://url.com
    razee.io/source-url: https://url.com
  creationTimestamp: "2022-11-08T19:45:05Z"
  name: example-secret
  namespace: default
  resourceVersion: "111111"
  uid: 1aaa1111-1a11-111a-a1a1-11111a1a1a1a
type: Opaque

Você também pode listar os campos em um segredo com os comandos ibmcloud oc ingress secret field ls e ibmcloud oc ingress secret get, mas as saídas incluem apenas o nome do campo e não o valor associado a ele.

Adicionando um campo secreto

Adicione um campo secreto a um segredo que não seja TLS executando o comando ibmcloud oc ingress secret field add com a opção --field. Você também pode usar esta opção para adicionar campos quando você criar um segredo com o comando ibmcloud oc ingress secret create. Essa opção não é compatível com segredos do tipo “ TLS ”.

Há três maneiras de especificar a opção --field. Aquele que você escolhe depende do tipo secreto e de como você quer nomear o campo no segredo.

Opções para adicionar campos a segredos não relacionados a TLS
Opção Formato Descrição Tipos de segredos suportados
Padrão --field <crn> O nome do campo incluído é o nome do campo padrão para o tipo de segredo do CRN especificado Todos os tipos de segredo que não sejam TLS
nomeado --field <name>=<crn> Utilize esta opção para especificar um nome para o campo adicionado. O nome do campo incluído é o valor especificado para <name>.. arbitrário - credenciais do IAM
Prefixado --field prefix=<crn> O nome do campo incluído é o default field name para o tipo de segredo especificado pelo CRN especificado, prefixado pelo nome do segredo especificado pelo <crn> e um sublinhado.
  • Credenciais do IAM
  • nome de usuário/senha
  • chave/valor
  • Credenciais personalizadas

Os nomes de campo padrão são arbitrary para segredos arbitrários, api_key para credenciais IAM, username para credenciais password de usuário e key para chave-valor.

O exemplo a seguir inclui três campos secretos, usando o mesmo segredo de credenciais do IAM, denominado iam, para demonstrar como as diferentes opções do --field afetam o nome do campo resultante É possível visualizar os campos incluídos em um segredo executando kubectl get secret e visualizando o bloco data da saída.

ibmcloud oc ingress secret field add --cluster example-cluster --name example-iam-secret --namespace openshift-ingress  --field crn:v1:bluemix:public:secrets-manager:us-south:a/1aa111aa-1a11-111a-aa1a-1111aa1aa111:secret:111a1111-11a1-11aa-a1a1-111aa12345aa --field custom_iam_name=crn:v1:bluemix:public:secrets-manager:us-south:a/1aa111aa-1a11-111a-aa1a-1111aa1aa111:secret:111a1111-11a1-11aa-a1a1-111aa12345aa --field prefix=crn:v1:bluemix:public:secrets-manager:us-south:a/1aa111aa-1a11-111a-aa1a-1111aa1aa111:secret:111a1111-11a1-11aa-a1a1-111aa12345aa

Exemplo campos listados no bloco data dos detalhes secretos.

data:
  api_key: bmZrUHR1VS1fNVpMOExsTmIxeTdQcXFTSENMc2pTUjRsNTQyTzZkZ2ZQMkk=  # Default field type using the default `api_key` field name
  custom_iam_name: bmZrUHR1VS1fNVpMOExsTmIxeTdQcXFTSENMc2pTUjRsNTQyTzZkZ2ZQMkk=  # Named field type using the specified `custom_iam_name` field name.
  iam_api_key: bmZrUHR1VS1fNVpMOExsTmIxeTdQcXFTSENMc2pTUjRsNTQyTzZkZ2ZQMkk= # Prefixed field type using the `iam` name in Secrets Manager followed by the `api_key` default name.

Atualização de campos secretos

Execute o comando ingress secret update para atualizar os valores de um campo secreto. Observe que isso não atualiza o CRN. Para obter mais informações e opções de comando, consulte a referência CLI.

ibmcloud oc ingress secret update --cluster example-cluster --name example-secret --namespace openshift-ingress

Removendo um campo secreto

Você pode remover um campo secreto de um segredo que não seja TLS. Para obter mais informações e opções de comando, consulte a referência CLI.

ibmcloud oc ingress secret field rm -c example-cluster --name example-secret --namespace openshift-ingress --field-name example-Field

Você pode verificar se o campo é removido verificando o bloco data dos detalhes do segredo.

kubectl get secret -n default example-secret -o yaml

FAQ dos segredos

Revise as respostas a perguntas comumente feitas sobre o gerenciamento de segredos em seu cluster.

Os meus segredos são atualizados automaticamente se eu não criar e registrar uma instância Secrets Manager ?
Se você não registra uma instância Secrets Manager para o seu cluster, seus segredos Ingress padrão continuam a atualizar automaticamente a cada 90 dias e são aplicados em seu cluster. No entanto, quaisquer segredos que você tenha criado que referência o segredo Ingress padrão não são atualizados automaticamente.
Cenário de Exemplo: Você tem um certificado Ingresso padrão no espaço de nomes default. Você executa o comando ibmcloud oc ingress secret create e referencia o CRN do certificado Ingresso padrão para espelhar o certificado no espaço de nomes istio-system. Sem uma instância Secrets Manager, o certificado Ingress padrão no espaço de nomes default atualiza automaticamente. No entanto, você é responsável por atualizar regularmente o certificado no espaço de nomes istio-system com os comandos **kubectl** ou outro método de rotação.
Criei segredos que referencia o certificado Ingresso padrão, mas não criei e registrei uma instância Secrets Manager. Como gerencio meus segredos?
Se você não registrar uma instância Secrets Manager, Red Hat OpenShift on IBM Cloud atualiza automaticamente apenas o segredo Ingress padrão. Você é responsável por gerenciar quaisquer outros segredos usando comandos kubectl ou outro método de rotação. Se os seus segredos referencia o certificado Ingresso padrão, remova-os usando ibmcloud ks ingress secret rm.