Règles de sécurité et d'autorisation pour la mise en réseau ambiante

Cette page vous explique comment créer des règles d'autorisation sur le réseau ambiant.

Prérequis

Avant de pouvoir suivre la procédure décrite dans ce document, vous devez remplir les conditions suivantes :

  • Un cluster GKE en cours d'exécution avec la mise en réseau ambiante Cloud Service Mesh activée.
  • Un espace de noms enregistré dans le réseau ambiant (par exemple, ambient-test) avec des exemples de charges de travail client et serveur déployés.
  • TLS mutuelle (mTLS) activée entre les charges de travail client et serveur à l'aide d'un GCPServerTLSPolicy (avec mtlsMode: Strict) et d'un GCPClientTLSPolicy. Les règles GCPAuthzPolicy basées sur l'identité qui correspondent à CLIENT_CERT_URI_SAN nécessitent que le protocole mTLS soit actif pour extraire l'identité SPIFFE du client.

Pour une configuration détaillée de l'environnement, consultez Préparer la mise en réseau ambiante GKE.

Stratégie de refus par défaut

Par défaut, l'API GKE Ambient Authorization Policy autorise tout le trafic, sauf s'il est limité par une règle, ce qui correspond au comportement standard de Kubernetes NetworkPolicy.

L'action DENY_BY_DEFAULT vous permet de modifier ce comportement par défaut. Lorsqu'elle est appliquée à un espace de noms, cette règle bloque tout le trafic vers les charges de travail de cet espace de noms, sauf si une règle ALLOW l'autorise explicitement.

Cette page vous explique comment configurer et utiliser DENY_BY_DEFAULT dans Cloud Service Mesh pour établir une posture sécurisée par défaut pour vos charges de travail.

Limites

Avant d'appliquer une règle DENY_BY_DEFAULT, tenez compte des limites suivantes :

  • Vous ne pouvez créer qu'une seule règle DENY_BY_DEFAULT par espace de noms.
  • Aucune règle ne peut être définie pour une stratégie avec l'action DENY_BY_DEFAULT.
  • Utilisez cette action pour définir une matchLabels: {} de référence à l'échelle de l'espace de noms afin de cibler tous les pods. Vous ne pouvez pas utiliser DENY_BY_DEFAULT pour les restrictions par pod.

Configurer une règle d'autorisation "refuser par défaut"

Pour établir une base de référence "refuser par défaut" dans un espace de noms et autoriser sélectivement l'accès à des charges de travail spécifiques, procédez comme suit :

  1. Créez et appliquez un GCPAuthzPolicy avec l'action définie sur DENY_BY_DEFAULT à votre espace de noms.

    cat <<EOF > deny-by-default-policy.yaml && kubectl apply -f deny-by-default-policy.yaml
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: deny-by-default-authz
  namespace: ambient-test
spec:
  action: DENY_BY_DEFAULT
  enforcementLevel: L4
  targetRefs:
  - group: ""
    kind: Pod
    selector:
      matchLabels: {}
EOF

    Le résultat est semblable à :

     gcpauthzpolicy.networking.gke.io/deny-by-default-authz created

    Par défaut, cette règle bloque tout le trafic entrant (est-ouest et entrant) vers les charges de travail de l'espace de noms ambient-test. Il ne limite pas le trafic sortant provenant des charges de travail de l'espace de noms.

  2. Pour autoriser sélectivement le trafic, créez et appliquez une règle ALLOW :

    cat <<EOF > allow-policy.yaml && kubectl apply -f allow-policy.yaml
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: allow-client-to-server
  namespace: ambient-test
spec:
  action: ALLOW
  enforcementLevel: L4
  targetRefs:
  - group: ""
    kind: Pod
    selector:
      matchLabels:
        app: server
  rules:
  - from:
      sources:
      - principals:
      - principalSelector: CLIENT_CERT_URI_SAN
        principal:
          type: Exact
          value: spiffe://PROJECT_ID.s3ns.svc.id.goog/ns/ambient-test/sa/client
EOF

    Remplacez PROJECT_ID par l'ID du projet.

    La propagation de la règle peut prendre jusqu'à trois minutes après l'acceptation du contrôleur. Patientez trois minutes avant de continuer.

  3. Testez la connectivité du client au serveur. Elle devrait aboutir, car elle correspond à la règle ALLOW.

    kubectl exec -it deploy/client -n ambient-test -- /bin/curl -fsLS server.ambient-test.svc.cluster.local

  4. Testez la connectivité du serveur à lui-même (ou à toute autre charge de travail sans règle d'autorisation explicite). Il devrait échouer en raison du règlement DENY_BY_DEFAULT.

    kubectl exec -it deploy/server -n ambient-test -- /bin/curl -fsLS server.ambient-test.svc.cluster.local

    Le résultat est semblable à :

    curl: (52) Empty reply from server.

Journalisation

Lorsqu'une requête est refusée par la règle d'autorisation, les journaux d'accès du proxy Ambient GKE contiennent les champs suivants dans la charge utile JSON :

  • jsonPayload.error_details : définie sur "- rbac_access_denied_matched_policy[none]"

Vous pouvez utiliser l'explorateur de journaux dans la console Cloud de Confiance pour afficher les entrées du journal d'accès pour les connexions refusées. Consultez Vérifier que le trafic est authentifié et autorisé.

Règles de sécurité de sortie

Pour inspecter et contrôler le trafic sortant des charges de travail de mise en réseau ambiante vers des points de terminaison externes ou Internet, vous pouvez acheminer le trafic de sortie via Secure Web Proxy (SWP).

Pour savoir comment configurer les ressources GCPBackend et GCPEgressRouting, consultez Router le trafic de sortie ambiant via Secure Web Proxy.