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 du 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 Pod to 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 vous offrent un mécanisme permettant de restreindre le trafic réseau entre les pods (souvent appelé trafic est/ouest) ainsi qu'entre les pods et les services externes. Les politiques réseau Kubernetes s'appliquent aux couches 3 et 4 du modèle OSI. Les politiques réseau utilisent des modules, des sélecteurs d'espace de noms et des étiquettes pour identifier les pods source et de 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 aux connexions entrantes ou 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 ainsi 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 module. 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 de sortie. 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

Débuter avec les politiques réseau - Suivez le principe du moindre privilège

Création d'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 en matière de politiques réseau. Commencez par créer une politique de refus total qui restreint tout le trafic entrant et sortant dans 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éation d'une règle pour autoriser les requêtes DNS

Une fois que la règle par défaut de tout refuser est en place, vous pouvez commencer à appliquer des règles supplémentaires, telles qu'une règle qui permet aux pods d'interroger CoreDNS pour la résolution de 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

allow-dns-access

Ajoutez progressivement des règles pour autoriser de manière sélective le flux de trafic entre les espaces de noms/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 à app-one partir declient-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 des politiques du 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-policy-controller des agents des nœuds

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

En outre, Amazon VPC CNI vous permet d'activer la collecte et l'exportation des journaux d'application des politiques vers Amazon Cloudwatch à partir des nœuds de travail EKS. Une fois activé, vous pouvez tirer parti de CloudWatchContainer Insights pour obtenir des informations sur votre utilisation liée aux politiques du 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 transitant par un VPC, telles que l'adresse IP et le port source et de destination, ainsi que les paquets acceptés/abandonnés. Ces informations peuvent être analysées pour détecter toute activité suspecte ou inhabituelle entre les ressources du VPC, y compris les pods. Toutefois, étant donné que les adresses IP des pods changent fréquemment lorsqu'ils sont remplacés, les journaux de flux peuvent ne pas être suffisants à eux seuls. Calico Enterprise complète 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é VPC AWS (SGs) 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 Kubernetes version 1.14-eks.3 ou supérieure), un groupe de sécurité de 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 des raisons de simplicité, 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 le plan de contrôle et les groupes de sécurité des groupes de nœuds se trouvent dans le https://docs.aws.amazon.com/eks/latest/userguide/secfichier -group-reqs.html. Les règles minimales pour le groupe de sécurité du plan de contrôle autorisent le port 443 en provenance du nœud de travail SG. Cette règle permet aux kubelets de communiquer avec le serveur d'API Kubernetes. Il inclut également le port 10250 pour le trafic sortant vers le nœud de travail SG ; 10250 est le port que 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 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 les services exécutés au sein du cluster et les services exécutés en dehors du cluster, tels qu'une base de données RDS, envisagez de créer des groupes de sécurité pour les pods. Avec les groupes de sécurité pour les modules, vous pouvez attribuer un groupe de sécurité existant à un ensemble de modules.

Vous pouvez contrôler les modules affectés à un groupe de sécurité en créant un SecurityGroupPolicy objet et en spécifiant a PodSelector ou ServiceAccountSelector a. Si les sélecteurs sont définis sur, le SGs référencé {} sera attribué SecurityGroupPolicy à tous les pods d'un espace de noms ou à tous les comptes de service d'un espace de noms. Assurez-vous d'avoir pris connaissance de 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 constituent un moyen natif d'AWS de contrôler le trafic réseau à l'intérieur et à l'extérieur de votre cluster sans la surcharge 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 restreindre la sortie du réseau à des domaines ou adresses IP spécifiques et entièrement qualifiés. Pour plus d'informations sur cette option, consultez la série en trois parties sur le contrôle du trafic de sortie dans Istio.

Quand utiliser la politique réseau par rapport au groupe de sécurité pour les pods ?

Quand utiliser la politique réseau Kubernetes

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

Meilleures pratiques en matière d'utilisation des groupes de sécurité pour les pods et de la politique réseau

En matière de sécurité du réseau, une approche multicouche est souvent la solution la plus efficace. L'utilisation combinée de la politique réseau Kubernetes et du SGP peut fournir une defense-in-depth stratégie robuste pour vos applications exécutées dans EKS.

Application de la politique Service Mesh 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 service applique les politiques à la couche 7 (application) du modèle OSI, tandis que les politiques réseau Kubernetes fonctionnent à la couche 3 (réseau) et à 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 de réseau globales, la prise en charge des règles basées sur les noms 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 les 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 de Calico peuvent être étendues aux espaces de noms, aux pods, aux comptes de service ou à l'échelle mondiale. Lorsque les politiques sont étendues à un compte de service, celui-ci associe un ensemble de ingress/egress règles à ce compte de service. Lorsque les règles RBAC appropriées sont en place, vous pouvez empêcher les équipes de contourner ces règles, ce qui permet aux professionnels de la sécurité informatique de déléguer l'administration des espaces de noms en toute sécurité. Isovalent, les responsables de Cilium, ont également étendu les politiques du réseau pour inclure la prise en charge partielle des règles de la 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 exécutées à 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 Kubernetes courantes à l'adresse. 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-politique-réseau.

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

Pour garantir 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 du moteur de politique réseau 3P vers le moteur de politique réseau VPC CNI, nous vous recommandons de convertir vos ressources NetworkPolicy CRDs 3P existantes vers les ressources NetworkPolicy Kubernetes avant d'activer la prise en charge de la politique 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 du pod.

Outil de migration

Pour faciliter votre processus de migration, nous avons développé un outil appelé K8s Network Policy Migrator qui convertit votre politique réseau existante en politiques Calico/Cilium réseau natives de CRDs 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 à garantir une transition harmonieuse.

Veuillez noter que l'outil de migration n'est actuellement pas pris en charge par l'équipe d'ingénierie des politiques du 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 bogues avec l'outil, nous vous demandons de bien vouloir créer un GitHubproblème. Vos commentaires sont précieux pour nous et nous aideront à améliorer continuellement nos services.

Ressources supplémentaires

Chiffrement en transit

Les applications qui doivent être conformes aux réglementations PCI, HIPAA ou autres peuvent avoir besoin de chiffrer les données pendant leur transit. De nos jours, le TLS est le choix de facto pour chiffrer le trafic sur le fil. 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 de chiffrement des 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 permettant de chiffrer 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 y a 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.

Interfaces réseau de conteneurs (CNIs)

WeaveNetpeut être configuré pour chiffrer automatiquement l'ensemble du trafic à l'aide du NaCl chiffrement pour le trafic de couverture et de l' IPsec ESP pour le trafic rapide des chemins de données.

Maillage de service

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 des certificats X.509 ou le Secret Discovery Service (SDS) d'Envoy. Linkerd et Istio prennent tous deux en charge les MTL.

Le aws-app-mesh-examplesGitHub référentiel fournit des instructions détaillées pour configurer les MTL à l'aide de certificats X.509 et de SPIRE en tant que fournisseur de SDS avec votre conteneur Envoy :

App Mesh prend également en charge le chiffrement 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 aws-app-mesh-examplesGitHub référentiel fournit des instructions détaillées 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 sont un moyen pour vous d'acheminer intelligemment le HTTP/S traffic that emanates from outside the cluster to services running inside the cluster. Oftentimes, these Ingresses are fronted by a layer 4 load balancer, like the Classic Load Balancer or the Network Load Balancer (NLB). Encrypted traffic can be terminated at different places within the network, e.g. at the load balancer, at the ingress resource, or the Pod. How and where you terminate your SSL connection will ultimately be dictated by your organization’s network security policy. For instance, if you have a policy that requires end-to-end encryption, you will have to decrypt the traffic at the Pod. This will place additional burden on your Pod as it will have to spend cycles establishing the initial handshake. Overall SSL/TLS traitement qui consomme beaucoup de CPU. Par conséquent, si vous en avez la flexibilité, essayez d'effectuer le déchargement SSL à l'entrée ou à l'équilibreur de charge.

Utiliser le chiffrement avec les équilibreurs de charge élastiques AWS

L'AWS Application Load Balancer (ALB) et le Network Load Balancer (NLB) prennent tous deux en charge le chiffrement des transports (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 écouteurs qui en ont besoin en faisant correspondre les certificats AWS Certificate Manager (ACM) disponibles à l'aide du champ host. À partir d'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 gestionnaire de certificats

Vous pouvez activer les protocoles TLS et MTL pour sécuriser les charges de travail de vos applications EKS à l'entrée, sur le pod et entre les pods à l'aide d'ACM Private Certificate Authority (CA) et de cert-manager, un module complémentaire populaire de Kubernetes permettant de distribuer, de renouveler et de révoquer des certificats. ACM Private CA est une autorité de certification hautement disponible, sécurisée et gérée 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), alors que l'autorité de certification par défaut stocke 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.

Mode CA de courte durée 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 de délivrer 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 d'ACM

Commencez par créer une autorité de certification privée en suivant les procédures décrites dans les documents techniques de l'autorité de certification privée d'ACM. Une fois que vous avez 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 indiquées 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 sur lesquels le gestionnaire de certificats et le plugin sont 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": "<CA_ARN>"
        }
    ]
}

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

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

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 à 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 privé CA que vous avez créé ci-dessus. Pour plus de détails sur la façon de spécifier et de demander des ressources de certificat, veuillez consulter le guide des ressources de certificats de cert-manager. Voir 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 l'autorité de certification privée ACM en tant qu'autorité de certification racine pour les MTL entre les charges de travail. Si vous optez pour cette approche, pensez à utiliser le mode CA éphémère dans ACM Private CA. Reportez-vous à la section précédente et à ce billet de blog pour plus de détails.

Comment fonctionne la signature des 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 aucun compte de service, Kubernetes en attribuera automatiquement un à votre charge de travail. De plus, les comptes de service installent 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 une autorité de certification. Lorsqu'une charge de travail démarre avec son proxy annexe envoyé, elle a besoin d'une identité attribuée par Istio pour être considérée comme fiable et autorisée à communiquer avec les autres services du maillage.

Pour obtenir cette identité auprès d'Istio, istio-agent envoie une demande connue sous le nom de demande de signature de certificat (ou CSR) au plan de contrôle 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. Le RA fait office de gardien qui s'assure que seule la CSR vérifiée parvient à l'AC. Une fois le CSR vérifié, il sera transmis au CA qui délivrera alors 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 de gestionnaire de certificats appelé agent Istio Certificate Signing Request (istio-csr) pour intégrer Istio à ACM Private CA. Cet agent permet de sécuriser les charges de travail Istio et les composants du plan de contrôle auprès des émetteurs de gestionnaires de certificats, en l'occurrence ACM Private CA. L'agent istio-csr expose le même service que celui fourni par istiod dans la configuration par défaut de validation des données entrantes. CSRs Sauf qu'après vérification, il convertira les demandes en ressources prises en charge par le gestionnaire de certificats (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 demande des certificats à ACM Private CA. Cette communication entre istio-csr et ACM Private CA est activée par le plugin AWS Private CA issuer. Le gestionnaire de certificats utilise ce plugin pour demander des certificats TLS à ACM Private CA. Le plugin é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 à l'origine du 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 CA privée

Demandes de signature de certificats Istio

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

Outils et ressources