Sécurisez Kubernetes avec Autorité de certification privée AWS - AWS Private Certificate Authority
Utilisation du gestionnaire de certificats entre comptesModèles de certificats pris en charge Exemples de solutions

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Sécurisez Kubernetes avec Autorité de certification privée AWS

Les conteneurs et applications Kubernetes utilisent des certificats numériques pour garantir une authentification et un chiffrement sécurisés. TLS Une solution largement adoptée pour la gestion du cycle de vie des TLS certificats dans Kubernetes est cert-manager, un module complémentaire de Kubernetes qui demande des certificats, les distribue aux conteneurs Kubernetes et automatise le renouvellement des certificats.

Autorité de certification privée AWS fournit un plug-in open source à cert-manager aws-privateca-issuer, pour les utilisateurs de cert-manager qui souhaitent configurer une autorité de certification sans stocker de clés privées dans le cluster. Les utilisateurs soumis à des exigences réglementaires en matière de contrôle d'accès et d'audit des opérations de l'autorité de certification peuvent utiliser cette solution pour améliorer l'auditabilité et garantir la conformité. Vous pouvez utiliser le plugin AWS Private CA Issuer avec Amazon Elastic Kubernetes Service EKS (Amazon), un Kubernetes AWS autogéré sur ou dans un Kubernetes sur site. Vous pouvez utiliser le plug-in avec x86 et ARM l'architecture.

Le schéma ci-dessous montre certaines des options disponibles pour une utilisation TLS dans un EKS cluster Amazon. Cet exemple de cluster, contenant diverses ressources, est situé derrière un équilibreur de charge. Les numéros identifient les points de terminaison possibles pour les communications TLS sécurisées, notamment l'équilibreur de charge externe, le contrôleur d'entrée, un module individuel au sein d'un service et une paire de modules communiquant de manière sécurisée entre eux.

Topologie Kubernetes simplifiée

  1. Terminaison au niveau de l'équilibreur de charge.

    Elastic Load Balancing (ELB) est un service AWS Certificate Manager intégré, ce qui signifie que vous pouvez le provisionner ACM auprès d'une autorité de certification privée, signer un certificat avec celle-ci et l'installer à l'aide de la ELB console. Cette solution fournit une communication cryptée entre un client distant et l'équilibreur de charge. Les données sont transmises non chiffrées au EKS cluster. Vous pouvez également fournir un certificat privé à un équilibreur autre que l'équilibreur de AWS charge pour qu'il y mette finTLS.

  2. Résiliation au niveau du contrôleur d'entrée Kubernetes.

    Le contrôleur d'entrée se trouve à l'intérieur du EKS cluster en tant qu'équilibreur de charge et routeur natifs. Si vous avez installé à la fois cert-manager et aws-privateca-issuerprovisionné le cluster avec une autorité de certification privée, Kubernetes peut installer un TLS certificat signé sur le contrôleur, lui permettant ainsi de servir de point de terminaison du cluster pour les communications externes. Les communications entre l'équilibreur de charge et le contrôleur d'entrée sont cryptées, et après l'entrée, les données sont transmises en clair aux ressources du cluster.

  3. Terminaison dans un pod.

    Chaque pod est un groupe d'un ou de plusieurs conteneurs qui partagent des ressources de stockage et de réseau. Si vous avez installé à la fois cert-manager et aws-privateca-issuerprovisionné le cluster avec une autorité de certification privée, Kubernetes peut installer des certificats signés TLS sur les pods selon les besoins. Une TLS connexion se terminant par un pod n'est pas disponible par défaut pour les autres pods du cluster.

  4. Communications sécurisées entre les pods.

    Vous pouvez également doter plusieurs pods de certificats leur permettant de communiquer entre eux. Les scénarios possibles sont les suivants :

    • Provisionnement à l'aide de certificats auto-signés générés par Kubernetes. Cela permet de sécuriser les communications entre les pods, mais les certificats auto-signés ne répondent HIPAA pas à nos exigences. FIPS

    • Provisionnement à l'aide de certificats signés par une autorité de certification privée. Comme dans les numéros 2 et 3 ci-dessus, cela nécessite d'installer à la fois cert-manager et aws-privateca-issuerde provisionner le cluster avec une autorité de certification privée. Kubernetes peut ensuite installer des TLS certificats signés sur les pods selon les besoins.

Utilisation du gestionnaire de certificats entre comptes

Les administrateurs disposant d'un accès multicompte à une autorité de certification peuvent utiliser cert-manager pour provisionner un cluster Kubernetes. Pour de plus amples informations, veuillez consulter Bonnes pratiques en matière de sécurité pour l'accès entre comptes aux données privées CAs.

Note

Seuls certains modèles de Autorité de certification privée AWS certificats peuvent être utilisés dans des scénarios entre comptes. Consultez Modèles de certificats pris en charge la liste des modèles disponibles.

Modèles de certificats pris en charge

Le tableau suivant répertorie les Autorité de certification privée AWS modèles qui peuvent être utilisés avec cert-manager pour provisionner un cluster Kubernetes.

Modèles pris en charge pour Kubernetes Support pour l'utilisation entre comptes
BlankEndEntityCertificate_ CSRPassthrough /Définition de V1
CodeSigningCertificateDéfinition de /V1
EndEntityCertificateDéfinition de /V1 ✓
EndEntityClientAuthCertificateDéfinition de /V1 ✓
EndEntityServerAuthCertificateDéfinition de /V1 ✓
OCSPSigningCertificateDéfinition de /V1

Exemples de solutions

Les solutions d'intégration suivantes montrent comment configurer l'accès Autorité de certification privée AWS à un EKS cluster Amazon.