Use um gerenciador de certificados personalizado

	Disponibilidade geral privada: usar um gerenciador de certificados personalizado com a Apigee híbrida Este recurso é oferecido como um GA particular para a Apigee híbrida versão 1.13.

Esse recurso oferece a opção de instalar um gerenciador de certificados personalizado para o Apigee híbrido com uma configuração modificada relacionada ao controle de acesso baseado em função (RBAC) usando permissões restritivas.

Observação: a Apigee fornece apenas um gráfico do Helm para que esse processo seja consistente com a instalação da Apigee híbrida.

Antes de começar

Atenção: devido à aplicação restritiva do RBAC, instale o gerenciador de certificados em um namespace em que você pretende instalar cargas de trabalho híbridas.

Esse recurso só está disponível em disponibilidade geral particular quando usado com a Apigee híbrida versões 1.13 e mais recentes.

Antes de prosseguir com as etapas de instalação, faça o download do gráfico do Helm usando os seguintes comandos:

export CHART_REPO=oci://us-docker.pkg.dev/apigee-release/apigee-hybrid-helm-charts
export CERT_MANAGER_VERSION=v1.14.5
helm pull $CHART_REPO/apigee-cert-manager --version $CERT_MANAGER_VERSION --untar

Como configurar o cert-manager personalizado

A configuração de um cert-manager personalizado requer as seguintes etapas:

1. Instalação nova de um cert-manager personalizado
2. Fazer upgrade para o cert-manager personalizado

Instalação nova de um cert-manager personalizado

Para realizar uma nova instalação de um gerenciador de certificados personalizado para uso com a Apigee híbrida, siga estas etapas:

1. Instale os CRDs usando kubectl com os seguintes comandos:

   export CERT_MANAGER_VERSION=v1.14.5
   kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/${CERT_MANAGER_VERSION}/cert-manager.crds.yaml
   

2. Instale o componente do cert-manager usando o gráfico do Helm

   helm install CERT_MANAGER_RELEASE_NAME apigee-cert-manager/ \
     --namespace APIGEE_NAMESPACE

   Depois, quando a nova versão do gráfico estiver disponível, você poderá fazer upgrade com helm upgrade:

   helm upgrade CERT_MANAGER_RELEASE_NAME apigee-cert-manager/ \
     --namespace APIGEE_NAMESPACE

Fazer upgrade para o cert-manager personalizado

Para migrar de um gerenciador de certificados não personalizado para uma versão personalizada, siga as etapas abaixo. Apenas um cert-manager pode ser executado no cluster em um determinado momento.

1. Desative os webhooks atuais e atualize a implantação para que não haja réplicas para uma migração perfeita:

     kubectl delete validatingwebhookconfiguration cert-manager-webhook
     kubectl delete mutatingwebhookconfiguration cert-manager-webhook
   
       # set the replicas to 0
   
     kubectl scale deployment cert-manager -n cert-manager --replicas=0
     kubectl scale deployment cert-manager-cainjector -n cert-manager --replicas=0
     kubectl scale deployment cert-manager-webhook -n cert-manager --replicas=0

2. Instale os CRDs:

   kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/${CERT_MANAGER_VERION}/cert-manager.crds.yaml

3. Instale o gerenciador de certificados personalizado:

   helm install CERT_MANAGER_RELEASE_NAME apigee-cert-manager/ \
     --namespace APIGEE_NAMESPACE

4. Quando a instalação terminar, exclua o cert-manager instalado anteriormente.
   Observação: não exclua os CRDs durante a etapa de limpeza.

Como instalar ou fazer upgrade da Apigee híbrida com um cert-manager personalizado

A instalação ou o upgrade híbrido com um gerenciador de certificados personalizado requer as seguintes alterações nos procedimentos de instalação ou atualização.

Mudanças na instalação da Apigee híbrida

Ao instalar a Apigee híbrida v1.13 ou mais recente com um cert-manager personalizado, faça a seguinte alteração no arquivo overrides.yaml antes de instalar os componentes da Apigee híbrida na Etapa 10: instalar a Apigee híbrida usando o Helm.

Atualize o arquivo overrides.yaml para informar ao operador onde encontrar os recursos relacionados ao cert-manager e permitir que ele use o emissor do cert-manager personalizado.

certManager:
  namespace: APIGEE_NAMESPACE

ao:
  certManagerCAIssuerEnabled: true

Mudanças no processo de upgrade da Apigee híbrida

Ao fazer upgrade da Apigee híbrida para a v1.13 ou mais recente com um cert-manager personalizado, faça as seguintes mudanças após as etapas em Preparar para o upgrade dos gráficos do Helm e antes Instalar os gráficos do Helm da Apigee híbrida:

1. Faça as seguintes mudanças no arquivo overrides.yaml para notificar o operador sobre onde encontrar os recursos relacionados ao cert-manager e permitir que ele use o ClusterIssuer do gerenciador de certificados personalizado.

   certManager:
     namespace: APIGEE_NAMESPACE
   
   ao:
     certManagerCAIssuerEnabled: true
   

2. Copie o secret apigee-ca atual do namespace cert-manager para seu namespace da Apigee:

   kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
   

3. Edite o arquivo apigee-ca.yaml para remover o parâmetro de namespace que identifica o namespace como cert-manager.
4. Aplique o secret apigee-ca ao namespace da Apigee com kubectl apply:

   kubectl -n APIGEE_NAMESPACE apply -f apigee-ca.yaml

Como reverter um upgrade da Apigee híbrida

Se você precisar reverter para uma versão anterior da Apigee híbrida, siga as instruções em Como reverter para uma versão anterior.

Como reverter e desinstalar o cert-manager personalizado

Reverter o cert-manager personalizado

Para reverter o cert-manager personalizado, siga estas etapas:

1. Desinstale a versão do Helm usando o seguinte comando:

   helm uninstall CERT_MANAGER_RELEASE_NAME

2. Instale o gerenciador de certificados normal (não personalizado) usando seu método preferido. Use a versão correspondente dos CRDs. Por exemplo, se você estiver usando o método kubectl para instalar o cert-manager, ele vai atualizar os CRDs para uma versão correspondente, já que o payload também inclui CRDs. Confirme se o método de instalação que você usa inclui os CRDs.

Desinstalar o gerenciador de certificados personalizado

Para desinstalar o cert-manager personalizado, siga estas etapas:

1. Desinstale a versão do Helm usando o seguinte comando:

   helm uninstall CERT_MANAGER_RELEASE_NAME

2. Exclua as CRDs com os seguintes comandos:

   export CERT_MANAGER_VERSION=v1.14.5
   kubectl delete -f https://github.com/cert-manager/cert-manager/releases/download/${CERT_MANAGER_VERSION}/cert-manager.crds.yaml

Infraestrutura como código (overrides.yaml)

O gráfico Helm oferece suporte a substituições conforme necessário, permitindo que você use um arquivo de substituições conforme necessário durante o processo de instalação ou upgrade. Para evitar confusão, recomendamos usar um nome de arquivo como cert-manager-overrides.yaml.

Consulte a documentação do cert-manager para conferir todas as configurações de substituição de cert-manager compatíveis.

Configurações comuns do gerenciador de certificados

Nos exemplos a seguir, mostramos como realizar algumas configurações comuns do gerenciador de certificados na Apigee híbrida.

Observação:

• Recomendamos o uso de um arquivo override.yaml dedicado para esse gerenciador de certificados personalizado. Se você estiver usando um arquivo de substituição, adicione a seguinte flag ao comando helm install para instalar ou fazer upgrade:

  --f CERT_MANAGER_OVERRIDES_FILE

• Não recomendamos o uso do Helm para gerenciar o ciclo de vida dos CRDs.
• Como o gráfico Helm modificado já está pré-configurado para um único namespace, não é possível substituir esse comportamento no seu arquivo de substituição. As mudanças de namespace precisam de mudanças de RBAC de "Role" para "ClusterRole", o que vai contra o propósito de ter essa configuração modificada.

Substituir imagens

Confira a seguir um exemplo de substituição de imagens com imagepullsecrets se você precisar hospedar a imagem de forma privada.

# cert-manager-overrides.yaml

global:
  # Reference to one or more secrets to be used when pulling images
  # ref: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
  #
  # For example:
  #  imagePullSecrets:
  #    - name: "image-pull-secret"
  imagePullSecrets: []


image:
  # Override the image tag to deploy by setting this variable.
  # If no value is set, the chart's appVersion will be used.
  repository: quay.io/jetstack/cert-manager-controller

webhook:
  image:
    # without a tag
    repository: quay.io/jetstack/cert-manager-webhook

cainjector:
  image:
    # without a tag
    repository: quay.io/jetstack/cert-manager-cainjector

startupapicheck:
  image:
    # without a tag
    repository: quay.io/jetstack/cert-manager-startupapicheck

NodeSelector e afinidade de nó

Na instalação da Apigee híbrida, é necessário usar nós separados para pods do Cassandra e outros pods. Se quiser executar o cert-manager no pool de nós não relacionado ao Cassandra, use a afinidade do nó:

# A Kubernetes Affinity, if required; see https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.27/#affinity-v1-core
#
# For example:
#   affinity:
#     nodeAffinity:
#      requiredDuringSchedulingIgnoredDuringExecution:
#        nodeSelectorTerms:
#        - matchExpressions:
#          - key: cloud.google.com/gke-nodepool
#            operator: In
#            values:
#            - master
affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: KEY
          operator: In
          values:
          - value for the non-C* node pool

webhook:
  affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: KEY
          operator: In
          values:
          - value for the non-C* node pool

cainjector:
  affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: KEY
          operator: In
          values:
          - value for the non C* node pool

Tolerâncias

Também é possível fornecer tolerâncias, conforme mostrado no exemplo a seguir:

# A list of Kubernetes Tolerations, if required; see https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.27/#toleration-v1-core
#
# For example:
#   tolerations:
#   - key: node.kubernetes.io/not-ready
#     operator: Equal
#     value: master
#     effect: NoSchedule
tolerations: []

webhook:
  tolerations: []

cainjector:
  tolerations: []

startupapicheck:
  tolerations: []