Vue d’ensemble de la sécurité du réseau d’applications Azure Kubernetes (préversion)

Azure Kubernetes Application Network sécurise la communication entre les services dans les clusters Azure Kubernetes Service (AKS) connectés via l’autorisation automatique TLS (mTLS) et l’autorisation basée sur l’identité. Il émet des identités de charge de travail et gère l’émission, la rotation et la validation des certificats pour activer la communication chiffrée, authentifiée et explicitement autorisée sans configuration manuelle, avec le chiffrement conforme à FIPS en transit.

Cet article fournit une vue d’ensemble des fonctionnalités de sécurité dans Azure Kubernetes Application Network, notamment mTLS, les identités de charge de travail, la gestion des certificats et les stratégies d’autorisation. Il décrit également les limitations et les étapes suivantes pour implémenter une communication sécurisée dans votre environnement Azure Kubernetes Application Network.

Limites

• Les certificats sont actuellement émis par une autorité de certification gérée par le réseau d’applications Azure Kubernetes et ne sont pas chaînés à une autorité de certification publique.

mTLS

Le réseau d’applications utilise mTLS pour fournir une communication chiffrée basée sur l’identité entre les charges de travail. Chaque service d’un cluster connecté au réseau d’applications reçoit automatiquement un certificat qui lui permet de prouver son identité et d’établir des connexions chiffrées approuvées avec d’autres services dans le même réseau d’applications. Le chiffrement en transit utilise le chiffrement conforme à FIPS.

stratégie de migration mTLS

Le réseau d’applications autorise actuellement le trafic chiffré et non chiffré. Cette approche garantit que les charges de travail existantes continuent de fonctionner normalement alors que les charges de travail nouvelles ou mises à jour utilisent automatiquement mTLS pour la communication sécurisée. Cela signifie que vous pouvez adopter mTLS pour sécuriser la communication entre vos charges de travail sans temps d’arrêt. Une fois la migration terminée, vous pouvez passer au mode strict afin que l’authentification soit appliquée.

Avantages de mTLS dans azure Kubernetes Application Network

mTLS dans azure Kubernetes Application Network vous aide à :

• Protéger les données en transit : tout le trafic de service à service peut être chiffré automatiquement (conforme FIPS).
• Vérifier l’identité du service : chaque charge de travail a un certificat racine et intermédiaire géré par le réseau d’applications unique.
• Simplifier les opérations : Application Network gère l’émission, la rotation et la révocation des certificats pour les utilisateurs.

Gestion des certificats

Azure Kubernetes Application Network fournit une gestion des certificats sauvegardée par Azure Key Vault qui émet et gère les certificats utilisés pour mTLS. Ce service établit une limite d’approbation partagée entre tous les clusters AKS connectés à la même ressource de réseau d’applications.

Application Network gère automatiquement l’intégralité du cycle de vie des certificats racines et intermédiaires, notamment l’approvisionnement, le renouvellement et la rotation. Cela garantit que les identités de charge de travail restent valides et que la communication reste sécurisée au fil du temps. Vous n’avez pas besoin de créer, stocker ou faire pivoter des certificats manuellement.

Le diagramme suivant illustre la hiérarchie de certificats dans Application Network, montrant comment l’autorité de certification racine, les autorités de certification intermédiaires et les certificats de charge de travail sont structurés pour établir une approbation entre les clusters connectés :

Hiérarchie des certificats et cycle de vie

Lorsqu’une ressource Réseau d’applications est créée, une autorité de certification racine est provisionnée pour servir d’ancre d’approbation pour le réseau d’applications. Lorsqu’un cluster AKS joint le réseau d’applications en tant que membre, Application Network émet un certificat intermédiaire pour ce membre signé par l’autorité de certification racine du réseau d’applications. Chaque cluster AKS connecté utilise son certificat intermédiaire géré par le réseau d’applications pour émettre des certificats de charge de travail de courte durée aux charges de travail de ce cluster.

Tous les certificats de charge de travail héritent de l’approbation de l’autorité de certification racine du réseau d’applications, en conservant une limite d’approbation unifiée sur la ressource. La rotation des certificats racines et intermédiaires est gérée de manière transparente pour les utilisateurs sans provoquer de temps d’arrêt ou de perturbations du trafic. Cette hiérarchie managée garantit une confiance vérifiable cohérente sur tous les clusters d’un réseau d’applications tout en conservant automatiquement la validité de chaque certificat.

Depuis n’importe quel cluster membre, vous pouvez obtenir le certificat CA racine à partir de la config map istio-root-cert dans l’espace de noms applink-system.

Types de certificats et périodes de rotation

Identité et autorisation de la charge de travail

À mesure que les applications augmentent, les services doivent souvent communiquer en toute sécurité entre différents espaces de noms et environnements au sein du même déploiement. La gestion des certificats et la garantie que chaque service peut vérifier à qui il parle peut rapidement devenir complexe et sujette aux erreurs. Azure Kubernetes Application Network élimine cette surcharge en affectant et en gérant automatiquement les identités de charge de travail.

Dans un environnement connecté au réseau d’applications, les charges de travail communiquent en toute sécurité à l’intérieur et entre les espaces de noms. Pour vous assurer que chaque service peut être approuvé et authentifié, Application Network affecte à chaque charge de travail une identité vérifiable qui représente son espace de noms et son compte de service.

Chaque charge de travail Application Network reçoit automatiquement une identité unique au format SPIFFE , qui inclut son espace de noms et son compte de service. L’identité est mise en forme comme suit :

spiffe://cluster.local/ns/<namespace>/sa/<service-account>

Cette identité est incorporée dans le certificat de charge de travail et est utilisée pour prouver l’identité du service lors de la communication avec d’autres charges de travail. Azure Kubernetes Application Network utilise ce modèle d’identité basé sur SPIFFE avec des stratégies d’autorisation Istio afin de définir des règles claires et cohérentes pour lesquelles les services sont autorisés à communiquer.

Définir des stratégies d’accès

Vous pouvez utiliser Istio AuthorizationPolicies pour contrôler les charges de travail autorisées à communiquer dans votre environnement. Ces stratégies vous permettent de définir l’accès en fonction des identités de charge de travail vérifiées plutôt que des emplacements réseau ou des adresses IP. Cette approche vous permet d’appliquer des contrôles d’accès cohérents, même lorsque les services sont mis à l’échelle et se déplacent entre les nœuds. Par exemple, vous pouvez autoriser uniquement des passerelles ou des charges de travail spécifiques à partir d’espaces de noms approuvés à appeler un service en référençant leurs identités SPIFFE dans la liste des principaux éléments de la stratégie, comme présenté dans l’exemple suivant :

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-gateway-to-app
  namespace: default
spec:
  selector:
    matchLabels:
      app: myApp
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/default/sa/myApp-gateway // see SPIFFE format above

Conseils de conception de stratégie

Lors de la conception de stratégies d’autorisation, gardez à l’esprit les meilleures pratiques suivantes :

• Spécifiez toujours l’espace de noms et le compte de service pour empêcher l’accès involontaire entre espaces de noms.
• Utilisez des principaux pour définir des identités de charge de travail explicites pour un accès précis.
• Utilisez des espaces de noms pour définir des limites de confiance plus larges si nécessaire.
• Évitez les règles qui correspondent uniquement aux noms de compte de service sans espaces de noms, car cela peut accorder l’accès entre les clusters ou les environnements.
• Combinez AuthorizationPolicies avec Kubernetes NetworkPolicies pour appliquer à la fois l’isolation basée sur l’identité et basée sur le réseau.

En combinant des identités managées par le réseau d’applications Azure Kubernetes, des certificats et des contrôles de stratégie, vous pouvez implémenter une communication de service basée sur des identités, à privilèges minimum, garantissant ainsi le trafic authentifié, chiffré et explicitement autorisé entre les charges de travail entre les clusters.

Contenu connexe

Pour en savoir plus sur Azure Kubernetes Application Network, consultez les articles suivants :

• Architecture du réseau d’applications Azure Kubernetes
• Vue d’ensemble de l’observabilité du réseau d’applications Azure Kubernetes