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écurité du réseau

La sécurité du réseau comporte plusieurs facettes. Le premier concerne l'application de règles qui limitent le flux de trafic réseau entre les services. Le second concerne le chiffrement du trafic pendant son transit. Les mécanismes permettant de mettre en œuvre ces mesures de sécurité sur EKS sont variés mais incluent souvent les éléments suivants :

Contrôle du trafic

Chiffrement de réseau

Politique du réseau

Au sein d'un cluster Kubernetes, toutes les communications de pod à pod sont autorisées par défaut. Bien que cette flexibilité puisse contribuer à promouvoir l'expérimentation, elle n'est pas considérée comme sûre. Les politiques réseau de Kubernetes fournissent un mécanisme permettant de restreindre le trafic réseau entre les Pods (souvent appelé East/West trafic) ainsi qu'entre les Pods et les services externes. Les politiques réseau de Kubernetes fonctionnent aux couches 3 et 4 du modèle OSI. Les politiques réseau utilisent des espaces, des sélecteurs d'espaces de noms et des étiquettes pour identifier les espaces source et destination, mais peuvent également inclure des adresses IP, des numéros de port, des protocoles ou une combinaison de ces éléments. Les politiques réseau peuvent être appliquées à la fois aux connexions entrantes et sortantes au pod, souvent appelées règles d'entrée et de sortie.

Grâce à la prise en charge native des politiques réseau par le plug-in Amazon VPC CNI, vous pouvez implémenter des politiques réseau pour sécuriser le trafic réseau dans les clusters Kubernetes. Cela s'intègre à l'API Kubernetes Network Policy en amont, garantissant la compatibilité et le respect des normes Kubernetes. Vous pouvez définir des politiques à l'aide de différents identifiants pris en charge par l'API en amont. Par défaut, tout le trafic entrant et sortant est autorisé vers un pod. Lorsqu'une politique réseau avec une entrée PolicyType est spécifiée, seules les connexions autorisées dans le pod sont celles provenant du nœud du pod et celles autorisées par les règles d'entrée. Il en va de même pour les règles d'évacuation. Si plusieurs règles sont définies, l'union de toutes les règles est prise en compte lors de la prise de décision. Ainsi, l'ordre d'évaluation n'a aucune incidence sur le résultat de la politique.

Recommandations

Commencer à utiliser les politiques réseau - Respectez le principe du moindre privilège

Créer une politique de refus par défaut

Comme pour les politiques RBAC, il est recommandé de suivre les principes d'accès les moins privilégiés avec les politiques réseau. Commencez par créer une politique de refus de tout qui restreint tout le trafic entrant et sortant au sein d'un espace de noms.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

default-deny (refus par défaut)

Créez une règle pour autoriser les requêtes DNS

Une fois que la règle « tout refuser » par défaut est en place, vous pouvez commencer à superposer des règles supplémentaires, comme une règle qui permet aux pods d'interroger CoreDNS pour la résolution des noms.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-access
  namespace: default
spec:
  podSelector:
    matchLabels: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53

autoriser l'accès au DNS

Ajoutez progressivement des règles pour autoriser de manière sélective le flux de trafic entre namespaces/pods

Comprenez les exigences de l'application et créez des règles d'entrée et de sortie précises selon les besoins. L'exemple ci-dessous montre comment restreindre le trafic entrant sur le port 80 vers et app-one depuisclient-one. Cela permet de minimiser la surface d'attaque et de réduire le risque d'accès non autorisé.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress-app-one
  namespace: default
spec:
  podSelector:
    matchLabels:
      k8s-app: app-one
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          k8s-app: client-one
    ports:
    - protocol: TCP
      port: 80

Allow-Ingress-App-One

Surveillance de l'application de la politique réseau

package kubernetes.admission
import data.kubernetes.networkpolicies

deny[msg] {
    input.request.kind.kind == "Pod"
    pod_label_value := {v["k8s-app"] | v := input.request.object.metadata.labels}
    contains_label(pod_label_value, "sample-app")
    np_label_value := {v["k8s-app"] | v := networkpolicies[_].spec.podSelector.matchLabels}
    not contains_label(np_label_value, "sample-app")
    msg:= sprintf("The Pod %v could not be created because it is missing an associated Network Policy.", [input.request.object.metadata.name])
}
contains_label(arr, val) {
    arr[_] == val
}

Résolution des problèmes

Surveillez les journaux vpc-network-policycontroller et node-agent

Activez les journaux du gestionnaire du contrôleur du plan de contrôle EKS pour diagnostiquer la fonctionnalité de la politique réseau. Vous pouvez diffuser les journaux du plan de contrôle vers un groupe de CloudWatch journaux et utiliser CloudWatch Log Insights pour effectuer des requêtes avancées. À partir des journaux, vous pouvez voir quels objets de point de terminaison de pod sont résolus selon une stratégie réseau, l'état de rapprochement des politiques et déboguer si la stratégie fonctionne comme prévu.

En outre, Amazon VPC CNI vous permet d'activer la collecte et l'exportation de journaux d'application des politiques vers Amazon Cloudwatch à partir des nœuds de travail EKS. Une fois activé, vous pouvez tirer parti de CloudWatch Container Insights pour fournir des informations sur votre utilisation en matière de politiques réseau.

Amazon VPC CNI fournit également un SDK qui fournit une interface permettant d'interagir avec les programmes eBPF sur le nœud. Le SDK est installé lorsqu'il aws-node est déployé sur les nœuds. Vous pouvez trouver le binaire du SDK installé dans le /opt/cni/bin répertoire du nœud. Au lancement, le SDK prend en charge les fonctionnalités fondamentales telles que l'inspection des programmes et des cartes eBPF.

sudo /opt/cni/bin/aws-eks-na-cli ebpf progs

Enregistrer les métadonnées du trafic réseau

AWS VPC Flow Logs capture les métadonnées relatives au trafic circulant via un VPC, telles que l'adresse IP source et de destination et le port, ainsi que les accepted/dropped paquets. Ces informations peuvent être analysées pour détecter toute activité suspecte ou inhabituelle entre les ressources du VPC, y compris les pods. Cependant, étant donné que les adresses IP des pods changent fréquemment au fur et à mesure de leur remplacement, les Flow Logs peuvent ne pas être suffisants à eux seuls. Calico Enterprise étend les journaux de flux avec des étiquettes de modules et d'autres métadonnées, ce qui facilite le déchiffrement des flux de trafic entre les modules.

Groupes de sécurité

EKS utilise les groupes de sécurité (SG) AWS VPC pour contrôler le trafic entre le plan de contrôle Kubernetes et les nœuds de travail du cluster. Les groupes de sécurité sont également utilisés pour contrôler le trafic entre les nœuds de travail, les autres ressources VPC et les adresses IP externes. Lorsque vous provisionnez un cluster EKS (avec la version 1.14-eks.3 ou supérieure de Kubernetes), un groupe de sécurité du cluster est automatiquement créé pour vous. Ce groupe de sécurité permet une communication sans entrave entre le plan de contrôle EKS et les nœuds des groupes de nœuds gérés. Pour simplifier, il est recommandé d'ajouter le cluster SG à tous les groupes de nœuds, y compris les groupes de nœuds non gérés.

Avant la version 1.14 de Kubernetes et la version eks.3 d'EKS, des groupes de sécurité distincts étaient configurés pour le plan de contrôle EKS et les groupes de nœuds. Les règles minimales et suggérées pour les groupes de sécurité du plan de contrôle et du groupe de nœuds se trouvent à https://docs.aws.amazon.com/eks/latest/userguide/sec-group-reqs.html. l'adresse Les règles minimales pour le groupe de sécurité du plan de contrôle autorisent le port 443 entrant depuis le nœud de travail SG. Cette règle permet aux kubelets de communiquer avec le serveur API Kubernetes. Il inclut également le port 10250 pour le trafic sortant vers le nœud de travail SG ; 10250 est le port sur lequel les kubelets écoutent. De même, les règles de groupe de nœuds minimum autorisent le port 10250 entrant depuis le plan de contrôle SG et le port 443 sortant vers le plan de contrôle SG. Enfin, il existe une règle qui permet une communication sans entrave entre les nœuds d'un groupe de nœuds.

Si vous devez contrôler la communication entre des services exécutés au sein du cluster et des services exécutés en dehors du cluster, tels qu'une base de données RDS, envisagez des groupes de sécurité pour les pods. Grâce aux groupes de sécurité pour les espaces, vous pouvez attribuer un groupe de sécurité existant à un ensemble de modules.

Vous pouvez contrôler quels pods sont affectés à un groupe de sécurité en créant un SecurityGroupPolicy objet et en spécifiant un PodSelector ou unServiceAccountSelector. Si vous définissez les sélecteurs sur, les SG référencés dans le {} seront affectés SecurityGroupPolicy à tous les pods d'un espace de noms ou à tous les comptes de service d'un espace de noms. Assurez-vous de vous être familiarisé avec toutes les considérations avant d'implémenter des groupes de sécurité pour les pods.

Bien que les groupes de sécurité pour les pods offrent un AWS-native moyen de contrôler le trafic réseau à l'intérieur et à l'extérieur de votre cluster sans les frais d'un démon de politique, d'autres options sont disponibles. Par exemple, le moteur de politique Cilium vous permet de référencer un nom DNS dans une politique réseau. Calico Enterprise inclut une option permettant de mapper les politiques réseau aux groupes de sécurité AWS. Si vous avez implémenté un maillage de services tel qu'Istio, vous pouvez utiliser une passerelle de sortie pour limiter la sortie du réseau à des domaines ou adresses IP spécifiques et complets. Pour plus d'informations sur cette option, consultez la série en trois parties sur le contrôle du trafic de sortie à Istio.

Quand utiliser Network Policy vs Security Group for Pods ?

Quand utiliser la politique réseau de Kubernetes

Quand utiliser les groupes de sécurité AWS pour les pods (SGP)

Meilleures pratiques utilisant les groupes de sécurité pour les pods et la politique réseau

En matière de sécurité réseau, une approche par couches est souvent la solution la plus efficace. L'utilisation combinée de la politique réseau de Kubernetes et du SGP peut fournir une stratégie de défense en profondeur robuste pour vos applications exécutées dans EKS.

Service Mesh Policy Enenforcement ou politique réseau Kubernetes

A service mesh est une couche d'infrastructure dédiée que vous pouvez ajouter à vos applications. Il vous permet d'ajouter de manière transparente des fonctionnalités telles que l'observabilité, la gestion du trafic et la sécurité, sans les ajouter à votre propre code.

Le maillage de services applique les politiques au niveau de la couche 7 (application) du modèle OSI, tandis que les politiques réseau Kubernetes fonctionnent au niveau de la couche 3 (réseau) et de la couche 4 (transport). Il existe de nombreuses offres dans cet espace, comme AWSAppMesh, Istio, Linkerd, etc.

Quand utiliser Service Mesh pour appliquer les politiques

Choisissez la politique réseau Kubernetes pour des cas d'utilisation plus simples

ThirdParty Moteurs de politique réseau

Envisagez un moteur de politique réseau tiers lorsque vous avez des exigences de politique avancées telles que des politiques réseau globales, la prise en charge des règles basées sur le nom d'hôte DNS, des règles de couche 7, des règles ServiceAccount basées et des deny/log actions explicites, etc. Calico est un moteur de politique open source de Tigera qui fonctionne bien avec EKS. Outre la mise en œuvre de l'ensemble complet des fonctionnalités de politique réseau de Kubernetes, Calico prend en charge des politiques réseau étendues avec un ensemble de fonctionnalités plus riche, notamment la prise en charge des règles de couche 7, par exemple HTTP, lorsqu'il est intégré à Istio. Les politiques Calico peuvent être étendues aux espaces de noms, aux pods, aux comptes de service ou à l'échelle mondiale. Lorsque les politiques sont limitées à un compte de service, un ensemble de ingress/egress règles est associé à ce compte de service. En mettant en place les règles RBAC appropriées, vous pouvez empêcher les équipes de passer outre à ces règles, permettant ainsi aux professionnels de la sécurité informatique de déléguer en toute sécurité l'administration des espaces de noms. Isovalent, les responsables de Cilium, ont également étendu les politiques réseau pour inclure une prise en charge partielle des règles de couche 7, par exemple HTTP. Cilium prend également en charge les noms d'hôte DNS, ce qui peut être utile pour restreindre le trafic entre Kubernetes Services/Pods et les ressources qui s'exécutent à l'intérieur ou à l'extérieur de votre VPC. En revanche, Calico Enterprise inclut une fonctionnalité qui vous permet de mapper une politique réseau Kubernetes à un groupe de sécurité AWS, ainsi qu'à des noms d'hôte DNS.

Vous trouverez une liste des politiques réseau courantes de Kubernetes sur https://github.com/ahmetb/kubernetes-network-policy-recipes. Un ensemble de règles similaires pour Calico est disponible sur https://docs.projectcalico.org/security/calico-network-policy.

Migration vers le moteur de politique réseau Amazon VPC CNI

Pour maintenir la cohérence et éviter tout comportement de communication inattendu entre les pods, il est recommandé de ne déployer qu'un seul moteur de stratégie réseau dans votre cluster. Si vous souhaitez migrer de 3P vers le moteur de politique réseau VPC CNI, nous vous recommandons de convertir vos NetworkPolicy CRD 3P existants en NetworkPolicy ressources Kubernetes avant d'activer la prise en charge des politiques réseau VPC CNI. Testez également les politiques migrées dans un cluster de test distinct avant de les appliquer dans votre environnement de production. Cela vous permet d'identifier et de résoudre tout problème ou incohérence potentiel dans le comportement de communication des pods.

Outil de migration

Pour faciliter votre processus de migration, nous avons développé un outil appelé K8s Network Policy Migrator qui convertit vos CRD de politique Calico/Cilium réseau existants en politiques réseau natives de Kubernetes. Après la conversion, vous pouvez tester directement les politiques réseau converties sur vos nouveaux clusters exécutant le contrôleur de politique réseau VPC CNI. L'outil est conçu pour vous aider à rationaliser le processus de migration et à assurer une transition en douceur.

Veuillez noter que l'outil de migration n'est actuellement pas pris en charge par l'équipe d'ingénierie des politiques réseau AWS VPC CNI. Il est mis à la disposition des clients dans la mesure du possible. Nous vous encourageons à utiliser cet outil pour faciliter votre processus de migration. Si vous rencontrez des problèmes ou des bugs avec l'outil, nous vous demandons de bien vouloir créer un GitHub problème. Vos commentaires sont précieux pour nous et contribueront à l'amélioration continue de nos services.

Ressources supplémentaires

Chiffrement en transit

Les applications qui doivent être conformes à la norme PCI, HIPAA ou à d'autres réglementations peuvent avoir besoin de chiffrer les données pendant leur transit. De nos jours, le protocole TLS est le choix de facto pour chiffrer le trafic sur le réseau. Le protocole TLS, comme son prédécesseur SSL, fournit des communications sécurisées sur un réseau à l'aide de protocoles cryptographiques. Le protocole TLS utilise un chiffrement symétrique dans lequel les clés permettant de chiffrer les données sont générées sur la base d'un secret partagé négocié au début de la session. Voici quelques méthodes de chiffrement des données dans un environnement Kubernetes.

Instances Nitro

Le trafic échangé entre les types d'instances Nitro suivants, par exemple C5n, G4, i3en, M5dn, M5n, P3dn, R5dn et R5n, est automatiquement chiffré par défaut. Lorsqu'il existe un saut intermédiaire, comme une passerelle de transit ou un équilibreur de charge, le trafic n'est pas chiffré. Consultez la section Chiffrement en transit pour plus de détails sur le chiffrement en transit ainsi que la liste complète des types d'instances qui prennent en charge le chiffrement réseau par défaut.

Maillage de services

Le chiffrement en transit peut également être mis en œuvre avec un maillage de services tel que App Mesh, Linkerd v2 et Istio. AppMesh prend en charge les mTL avec X.509 des certificats ou le service de découverte secret (SDS) d'Envoy. Linkerd et Istio prennent tous deux en charge les mTLS.

Le GitHub référentiel aws-app-mesh-examples fournit des procédures pas à pas pour configurer les mTL à l'aide de X.509 certificats et SPIRE en tant que fournisseur de SDS avec votre conteneur Envoy :

App Mesh prend également en charge le cryptage TLS avec un certificat privé émis par AWS Certificate Manager (ACM) ou un certificat stocké sur le système de fichiers local du nœud virtuel.

Le GitHub référentiel aws-app-mesh-examples fournit des procédures pas à pas pour configurer le protocole TLS à l'aide de certificats émis par ACM et de certificats fournis avec votre conteneur Envoy :

Contrôleurs d'entrée et équilibreurs de charge

Les contrôleurs d'entrée vous permettent d'acheminer intelligemment le HTTP/S trafic provenant de l'extérieur du cluster vers les services exécutés à l'intérieur du cluster. Souvent, ces entrées sont précédées d'un équilibreur de charge de couche 4, comme le Classic Load Balancer ou le Network Load Balancer (NLB). Le trafic chiffré peut être terminé à différents endroits du réseau, par exemple au niveau de l'équilibreur de charge, de la ressource d'entrée ou du Pod. La manière et l'endroit où vous mettrez fin à votre connexion SSL seront en fin de compte dictés par la politique de sécurité réseau de votre organisation. Par exemple, si votre politique exige un chiffrement de bout en bout, vous devrez déchiffrer le trafic au niveau du Pod. Cela alourdira la charge de travail de votre Pod, car il devra passer des cycles à établir la poignée de main initiale. Dans l'ensemble, SSL/TLS le traitement est très gourmand en ressources processeur. Par conséquent, si vous avez la flexibilité nécessaire, essayez d'effectuer le déchargement SSL au niveau de l'Ingress ou de l'équilibreur de charge.

Utilisez le chiffrement avec les équilibreurs de charge AWS Elastic

L'AWS Application Load Balancer (ALB) et le Network Load Balancer (NLB) prennent tous deux en charge le chiffrement du transport (SSL et TLS). L'alb.ingress.kubernetes.io/certificate-arnannotation pour l'ALB vous permet de spécifier les certificats à ajouter à l'ALB. Si vous omettez l'annotation, le contrôleur tentera d'ajouter des certificats aux auditeurs qui en ont besoin en faisant correspondre les certificats AWS Certificate Manager (ACM) disponibles à l'aide du champ hôte. À partir de EKS v1.15, vous pouvez utiliser l'service.beta.kubernetes.io/aws-load-balancer-ssl-certannotation avec le NLB comme indiqué dans l'exemple ci-dessous.

apiVersion: v1
kind: Service
metadata:
  name: demo-app
  namespace: default
  labels:
    app: demo-app
  annotations:
     service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
     service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "<certificate ARN>"
     service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443"
     service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "http"
spec:
  type: LoadBalancer
  ports:
  - port: 443
    targetPort: 80
    protocol: TCP
  selector:
    app: demo-app
//---
kind: Deployment
apiVersion: apps/v1
metadata:
  name: nginx
  namespace: default
  labels:
    app: demo-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-app
  template:
    metadata:
      labels:
        app: demo-app
    spec:
      containers:
        - name: nginx
          image: nginx
          ports:
            - containerPort: 443
              protocol: TCP
            - containerPort: 80
              protocol: TCP

Vous trouverez ci-dessous d'autres exemples de SSL/TLS résiliation.

ACM Private CA avec cert-manager

Vous pouvez activer TLS et mTLS pour sécuriser les charges de travail de vos applications EKS à l'entrée, sur le pod et entre les pods à l'aide de l'ACM Private Certificate Authority (CA) et de cert-manager, un module complémentaire populaire de Kubernetes pour distribuer, renouveler et révoquer des certificats. ACM Private CA est une autorité de certification gérée, sécurisée et hautement disponible, sans les coûts initiaux et de maintenance liés à la gestion de votre propre autorité de certification. Si vous utilisez l'autorité de certification Kubernetes par défaut, il est possible d'améliorer votre sécurité et de répondre aux exigences de conformité avec ACM Private CA. L'autorité de certification privée ACM sécurise les clés privées dans les modules de sécurité matériels FIPS 140-2 de niveau 3 (très sécurisés), par rapport à l'autorité de certification par défaut stockant les clés codées en mémoire (moins sécurisée). Une autorité de certification centralisée vous permet également de mieux contrôler et d'améliorer l'auditabilité des certificats privés, à la fois à l'intérieur et à l'extérieur d'un environnement Kubernetes.

Short-Lived Mode CA pour le protocole TLS mutuel entre les charges de travail

Lorsque vous utilisez ACM Private CA pour mTLS dans EKS, il est recommandé d'utiliser des certificats de courte durée avec un mode CA de courte durée. Bien qu'il soit possible d'émettre des certificats de courte durée en mode CA à usage général, l'utilisation du mode CA de courte durée s'avère plus rentable (environ 75 % moins cher que le mode général) dans les cas d'utilisation où de nouveaux certificats doivent être émis fréquemment. En outre, vous devez essayer d'aligner la période de validité des certificats privés sur la durée de vie des pods de votre cluster EKS. Pour en savoir plus sur ACM Private CA et ses avantages, cliquez ici.

Instructions de configuration de l'ACM

Commencez par créer une autorité de certification privée en suivant les procédures fournies dans la documentation technique d'ACM Private CA. Une fois que vous disposez d'une autorité de certification privée, installez cert-manager en suivant les instructions d'installation habituelles. Après avoir installé cert-manager, installez le plugin Private CA Kubernetes cert-manager en suivant les instructions de configuration figurant dans. GitHub Le plugin permet à cert-manager de demander des certificats privés à ACM Private CA.

Maintenant que vous disposez d'une autorité de certification privée et d'un cluster EKS avec cert-manager et le plugin installés, il est temps de définir les autorisations et de créer l'émetteur. Mettez à jour les autorisations IAM du rôle de nœud EKS pour autoriser l'accès à ACM Private CA. Remplacez le <CA_ARN> par la valeur de votre autorité de certification privée :

{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Sid": "awspcaissuer",
            "Action": [
                "acm-pca:DescribeCertificateAuthority",
                "acm-pca:GetCertificate",
                "acm-pca:IssueCertificate"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:acm-pca:us-west-2:123456789012:certificate-authority/12345678-1234-1234-1234-123456789012"
        }
    ]
}

Les rôles de service pour les comptes IAM ou IRSA peuvent également être utilisés. Veuillez consulter la section Ressources supplémentaires ci-dessous pour des exemples complets.

Créez un émetteur dans Amazon EKS en créant un fichier de définition de ressource personnalisé nommé cluster-issuer.yaml contenant le texte suivant, en remplaçant <CA_ARN> et <Region> en fournissant des informations par votre autorité de certification privée.

apiVersion: awspca.cert-manager.io/v1beta1
kind: AWSPCAClusterIssuer
metadata:
          name: demo-test-root-ca
spec:
          arn: <CA_ARN>
          region: <Region>

Déployez l'émetteur que vous avez créé.

kubectl apply -f cluster-issuer.yaml

Votre cluster EKS est configuré pour demander des certificats auprès de Private CA. Vous pouvez désormais utiliser la Certificate ressource de cert-manager pour émettre des certificats en remplaçant les valeurs du issuerRef champ par l'émetteur de CA privé que vous avez créé ci-dessus. Pour plus de détails sur la manière de spécifier et de demander des ressources de certificat, veuillez consulter le guide des ressources de certification de cert-manager. Vous trouverez des exemples ici.

ACM Private CA avec Istio et cert-manager

Si vous exécutez Istio dans votre cluster EKS, vous pouvez empêcher le plan de contrôle Istio (en particulieristiod) de fonctionner en tant qu'autorité de certification (CA) racine et configurer ACM Private CA comme autorité de certification racine pour les mTL entre les charges de travail. Si vous optez pour cette approche, envisagez d'utiliser le mode CA de courte durée dans ACM Private CA. Reportez-vous à la section précédente et à ce billet de blog pour plus de détails.

Fonctionnement de la signature de certificats dans Istio (par défaut)

Les charges de travail dans Kubernetes sont identifiées à l'aide de comptes de service. Si vous ne spécifiez pas de compte de service, Kubernetes en attribuera automatiquement un à votre charge de travail. De plus, les comptes de service génèrent automatiquement un jeton associé. Ce jeton est utilisé par le compte de service pour les charges de travail afin de s'authentifier auprès de l'API Kubernetes. Le compte de service peut être suffisant comme identité pour Kubernetes, mais Istio possède son propre système de gestion des identités et sa propre autorité de certification. Lorsqu'une charge de travail démarre avec son proxy Envoy Sidecar, elle a besoin d'une identité attribuée par Istio pour être considérée comme fiable et autorisée à communiquer avec d'autres services du maillage.

Pour obtenir cette identité auprès d'Istio, il istio-agent envoie une demande appelée demande de signature de certificat (ou CSR) au plan de contrôle d'Istio. Ce CSR contient le jeton du compte de service afin que l'identité de la charge de travail puisse être vérifiée avant d'être traitée. Ce processus de vérification est géré paristiod, qui agit à la fois en tant qu'autorité d'enregistrement (ou RA) et en tant que CA. La RA joue le rôle de gardien qui s'assure que seule la CSR vérifiée est transmise à l'autorité de certification. Une fois le CSR vérifié, il sera transmis à l'autorité de certification qui émettra un certificat contenant une identité SPIFFE avec le compte de service. Ce certificat est appelé document d'identité vérifiable SPIFFE (ou SVID). Le SVID est attribué au service demandeur à des fins d'identification et pour chiffrer le trafic en transit entre les services communicants.

Flux par défaut pour les demandes de signature de certificats Istio :

Comment fonctionne la signature de certificats dans Istio avec ACM Private CA

Vous pouvez utiliser un module complémentaire cert-manager appelé agent de demande de signature de certificat Istio (istio-csr) pour intégrer Istio à ACM Private CA. Cet agent permet de sécuriser les charges de travail et les composants du plan de contrôle d'Istio auprès des émetteurs de certificats, en l'occurrence ACM Private CA. L'agent istio-csr expose le même service que celui utilisé par istiod dans la configuration par défaut de validation des CSR entrants. Sauf qu'après vérification, il convertira les demandes en ressources prises en charge par Cert Manager (c'est-à-dire des intégrations avec des émetteurs de CA externes).

Chaque fois qu'un CSR provient d'une charge de travail, il est transmis à istio-csr, qui demandera des certificats à ACM Private CA. Cette communication entre istio-csr et ACM Private CA est activée par le plug-in d'émetteur AWS Private CA. Cert Manager utilise ce plug-in pour demander des certificats TLS à ACM Private CA. Le plug-in émetteur communiquera avec le service ACM Private CA pour demander un certificat signé pour la charge de travail. Une fois le certificat signé, il sera renvoyé à istio-csr, qui lira la demande signée et la renverra à la charge de travail qui a initié le CSR.

Flux pour les demandes de signature de certificats Istio avec istio-csr

image : :istio-csr-with-acm-private-ca.png [Flux pour les demandes de signature de certificats Istio avec istio-csr]

Instructions de configuration d'Istio avec autorité de certification privée

Demandes de signature de certificats Istio

image : :istio-csr-requests.png [Demandes de signature de certificats Istio]

Outils et ressources