Utiliser un cert-manager personnalisé

Version en disponibilité générale privée : utiliser un gestionnaire de certificats personnalisé avec Apigee hybrid

Cette fonctionnalité est proposée en version en disponibilité générale privée pour Apigee hybrid version 1.13.

Cette fonctionnalité vous permet d'installer un cert-manager personnalisé pour Apigee hybrid avec une configuration liée au contrôle des accès basé sur les rôles (RBAC) modifiée à l'aide d'autorisations restrictives.

Avant de commencer

Avant de poursuivre l'installation, téléchargez le chart Helm à l'aide des commandes suivantes : 

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

Configurer le cert-manager personnalisé

Pour configurer un cert-manager personnalisé, procédez comme suit :

  1. Nouvelle installation d'un cert-manager personnalisé
  2. Passer au cert-manager personnalisé

Nouvelle installation d'un cert-manager personnalisé

Pour effectuer une nouvelle installation d'un cert-manager personnalisé à utiliser avec Apigee hybrid, procédez comme suit :

  1. Installez les CRD à l'aide de kubectl, à l'aide des commandes suivantes : 
    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. Installez le composant cert-manager à l'aide du chart Helm. 
    helm install CERT_MANAGER_RELEASE_NAME apigee-cert-manager/ \
  --namespace APIGEE_NAMESPACE

    Par la suite, lorsque la nouvelle version du chart sera disponible, vous pouvez la mettre à niveau avec helm upgrade :

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

Passer au cert-manager personnalisé

Pour migrer d'un cert-manager non personnalisé existant vers une version personnalisée, procédez comme suit. Un seul cert-manager peut s'exécuter dans le cluster à un moment donné.

  1. Désactivez les webhooks existants et mettez à jour le déploiement pour qu'il n'ait aucune instance répliquée pour une migration fluide : 
      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. Installez les CRD: 
    kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/${CERT_MANAGER_VERION}/cert-manager.crds.yaml
  3. Installez le cert-manager personnalisé : 
    helm install CERT_MANAGER_RELEASE_NAME apigee-cert-manager/ \
  --namespace APIGEE_NAMESPACE
  4. Une fois l'installation terminée, vous pouvez supprimer le cert-manager précédemment installé.

Installer ou mettre à niveau Apigee hybrid avec un cert-manager personnalisé

Pour installer ou mettre à niveau Apigee hybrid avec un cert-manager personnalisé, vous devez apporter les modifications suivantes aux procédures d'installation ou de mise à niveau.

Modifications apportées à l'installation d'Apigee hybrid

Lorsque vous installez Apigee hybrid v1.13 ou version ultérieure avec un cert-manager personnalisé, apportez la modification suivante dans votre fichier overrides.yaml avant d'installer les composants Apigee hybrid dans l'Étape 10 : Installer Apigee hybrid à l'aide de Helm.

Mettez à jour votre fichier overrides.yaml pour indiquer à l'opérateur où trouver les ressources associées à cert-manager et lui permettre d'utiliser l'émetteur de cert-manager personnalisé. 

certManager:
  namespace: APIGEE_NAMESPACE

ao:
  certManagerCAIssuerEnabled: true

Modifications apportées au processus de mise à niveau d'Apigee hybrid

Lorsque vous mettez à niveau Apigee hybrid vers la version 1.13 ou une version ultérieure avec un cert-manager personnalisé, apportez les modifications suivantes après avoir suivi la procédure décrite dans Préparer la mise à niveau des charts Helm et avant d'installer les charts Helm d'Apigee hybrid :

  1. Apportez les modifications suivantes dans votre fichier overrides.yaml pour indiquer à l'opérateur où trouver les ressources associées à cert-manager et lui permettre d'utiliser le ClusterIssuer du cert-manager personnalisé. 
    certManager:
  namespace: APIGEE_NAMESPACE

ao:
  certManagerCAIssuerEnabled: true
  2. Copiez le secret apigee-ca existant de l'espace de noms cert-manager vers votre espace de noms apigee : 
    kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
  3. Modifiez le fichier apigee-ca.yaml pour supprimer le paramètre d'espace de noms qui identifie l'espace de noms en tant que cert-manager.
  4. Appliquez le secret apigee-ca à votre espace de noms apigee avec kubectl apply : 
    kubectl -n APIGEE_NAMESPACE apply -f apigee-ca.yaml

Annuler une mise à niveau d'Apigee hybrid

Si vous devez effectuer un rollback vers une version précédente d'Apigee hybrid, suivez les instructions de la section Effectuer un rollback vers la version précédente.

Effectuer un rollback et désinstaller le cert-manager personnalisé

Rétablir le cert-manager personnalisé

Pour effectuer un rollback de cert-manager personnalisé, procédez comme suit :

  1. Désinstallez la version de Helm à l'aide de la commande suivante : 
    helm uninstall CERT_MANAGER_RELEASE_NAME
  2. Installez le cert-manager standard (non personnalisé) à l'aide de la méthode de votre choix. Veillez à utiliser la version correspondante des définitions de ressources personnalisées. Par exemple, si vous utilisez la méthode kubectl pour installer le cert-manager, les définitions de ressources personnalisées seront mises à jour vers une version correspondante, car la charge utile inclura également des définitions de ressources personnalisées. Assurez-vous que la méthode d'installation que vous utilisez inclut les définitions de ressources personnalisées.

Désinstaller le cert-manager personnalisé

Pour désinstaller le cert-manager personnalisé, procédez comme suit :

  1. Désinstallez la version de Helm à l'aide de la commande suivante : 
    helm uninstall CERT_MANAGER_RELEASE_NAME
  2. Supprimez les objets CRD à l'aide des commandes suivantes : 
    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

Infrastructure as Code (overrides.yaml)

Le graphique Helm accepte les forçages si nécessaire, ce qui vous permet d'utiliser un fichier de forçages si nécessaire lors du processus d'installation ou de mise à niveau. Pour éviter toute confusion, nous vous recommandons d'utiliser un nom de fichier tel que cert-manager-overrides.yaml.

Consultez la documentation cert-manager pour connaître toutes les configurations de remplacement cert-manager acceptées.

Configurations courantes de cert-manager

Les exemples suivants montrent comment effectuer certaines configurations courantes de cert-manager dans Apigee hybrid.

Images de remplacement

Voici un exemple de forçage d'images avec imagepullsecrets si vous devez héberger l'image en privé. 

# 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 et affinité de nœud

Lors de l'installation d'Apigee Hybrid, vous devez utiliser des nœuds distincts pour les pods Cassandra et les autres pods. Si vous souhaitez exécuter cert-manager dans le pool de nœuds non lié à Cassandra, vous pouvez utiliser l'affinité de nœuds : 

# 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

Tolérances

Vous pouvez également fournir des tolérances, comme illustré dans l'exemple suivant : 

# 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: []