Configurer des règles d'autorisation sur les side-cars sur GKE

Aperçu — Règles d'autorisation sur les side-cars

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une prise en charge limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Cette page explique comment configurer différents types de stratégies d'autorisation sur les side-cars Cloud Service Mesh sur GKE.

Avant de commencer

Vous devez connaître l'API Gateway et les extensions d'autorisation.

Avant de créer une règle d'autorisation, vous devez effectuer les étapes suivantes :

Connectez-vous à votre compte Google Cloud . Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de nos produits en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits sans frais pour exécuter, tester et déployer des charges de travail.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Network Security, Network Services APIs, if any are not already enabled.

Roles required to enable APIs

To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

Enable the APIs

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Network Security, Network Services APIs, if any are not already enabled.

Roles required to enable APIs

To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

Enable the APIs

Remarque : Après avoir créé ou modifié une règle d'autorisation, l'application de cette règle par les side-cars peut prendre jusqu'à 15 minutes.

AuthzPolicy à l'échelle de l'espace de noms

Si vous souhaitez refuser un modèle de trafic attendu pour l'ensemble de l'espace de noms, configurez une règle d'autorisation pour refuser toutes les requêtes HTTP entrantes vers toutes les charges de travail d'un espace de noms :

cat >ns-authz-policy-deny.yaml <<EOF
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: ns-authz
  namespace: NAMESPACE
spec:
  targetRefs:
  - group: ""
    kind: Pod
    selector: {}
  rules:
  - to:
      operations:
      - paths:
        - type: Prefix
          value: "/bad_token"
  action: DENY
  enforcementLevel: L7
EOF
kubectl apply -f ns-authz-policy-deny.yaml

La valeur selector: {} vide cible tous les pods de l'espace de noms.

Si vous souhaitez autoriser un modèle de trafic attendu pour l'ensemble de l'espace de noms, configurez une règle d'autorisation pour autoriser toutes les requêtes HTTP entrantes vers toutes les charges de travail d'un espace de noms :

cat >ns-authz-policy-allow.yaml <<EOF
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: ns-authz
  namespace: NAMESPACE
spec:
  targetRefs:
  - group: ""
    kind: Pod
    selector: {}
  rules:
  - to:
      operations:
      - paths:
        - type: Prefix
          value: "/headers"
        methods: ["GET"]
  action: ALLOW
  enforcementLevel: L7
EOF
kubectl apply -f ns-authz-policy-allow.yaml

La valeur selector: {} vide cible tous les pods de l'espace de noms.

Refuser les requêtes entrantes vers une charge de travail

Si vous avez une charge de travail qui n'est censée effectuer que des appels sortants, comme un job Cron, configurez une règle d'autorisation pour refuser toutes les requêtes HTTP entrantes vers la charge de travail :

cat >deny-path-authz-policy.yaml <<EOF
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: my-workload-authz
  namespace: NAMESPACE
spec:
  targetRefs:
  - group: ""
    kind: Pod
    selector:
      matchLabels:
        app: EXAMPLE_APP
  rules:
  - to:
      operations:
      - paths:
        - type: Prefix
          value: "/deny_path"
  action: DENY
  enforcementLevel: L7
EOF
kubectl apply -f deny-path-authz-policy.yaml

Le résultat est semblable à :

gcpauthzpolicy.networking.gke.io/my-workload-authz created

Une fois cette règle appliquée, toute requête HTTP entrante vers le chemin d'accès /deny_path sur les pods correspondant à l'application EXAMPLE_APP sera rejetée et l'appelant recevra un code de réponse HTTP 403 (Accès refusé).

Autoriser des requêtes entrantes spécifiques vers une charge de travail

Vous pouvez également configurer une règle ALLOW qui n'autorise que les requêtes correspondant à un critère spécifique, tout en rejetant les autres.

L'exemple suivant configure une règle d'autorisation sur le déploiement example-app pour n'autoriser que les requêtes mTLS provenant de pods avec l'identité spiffe://cluster.local/NAMESPACE/pod1.

cat >allow-authz-policy.yaml <<EOF
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: my-workload-authz
  namespace: NAMESPACE
spec:
  targetRefs:
  - group: ""
    kind: Pod
    selector:
      matchLabels:
        app: EXAMPLE_APP
  rules:
  - from:
      sources:
      - principals:
        - principal:
            type: Exact
            value: "spiffe://cluster.local/NAMESPACE/pod1"
  action: ALLOW
  enforcementLevel: L7
EOF
kubectl apply -f allow-authz-policy.yaml

Le résultat est semblable à :

gcpauthzpolicy.networking.gke.io/my-workload-authz created

Seules les requêtes entrantes authentifiées à l'aide de mTLS présentant l'identité SPIFFE exacte spiffe://cluster.local/NAMESPACE/pod1 recevront un code HTTP 200 OK. Toute autre requête sera rejetée par le proxy avec une erreur HTTP 403 (accès refusé).

Déléguer à un moteur d'autorisation externe

Vous pouvez utiliser votre propre moteur d'autorisation et configurer Cloud Service Mesh pour déléguer toutes les décisions d'autorisation d'une charge de travail au moteur configuré.

1. Installez la CRD GCPAuthzExtension si ce n'est pas déjà fait :

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-gateway-api/main/config/crd/networking.gke.io_gcpauthzextensions.yaml
   

2. Déployez une charge de travail d'extension d'autorisation basée sur un appel dans Kubernetes compatible avec le protocole gRPC ext_proc et configurez une ressource d'extension d'autorisation :

   cat >authz-extension.yaml <<EOF
   apiVersion: networking.gke.io/v1
   kind: GCPAuthzExtension
   metadata:
     name: my-authz-ext
     namespace: NAMESPACE
   spec:
     backendRef:
       group: ""
       kind: Service
       name: authz-service
       port: PORT
     authority: "authz-service.NAMESPACE.svc.cluster.local"
     forwardHeaders:
     - Authorization
     failOpen: false
     timeout: "100ms"
     wireFormat: ExtProcGRPC
   EOF
   kubectl apply -f authz-extension.yaml
   

   Remplacez les éléments suivants :

   • NAMESPACE : espace de noms du service authz-service et des charges de travail.
   • PORT : port du service authz-service qui diffuse l'API gRPC ext_proc.

   Cette commande crée une extension d'autorisation basée sur un appel qui s'exécute en tant que service Kubernetes authz-service.

   Le résultat est semblable à :

   gcpauthzextension.networking.gke.io/my-authz-ext created
   

3. Configurez la règle d'autorisation pour déléguer les décisions d'autorisation de la charge de travail à l'extension d'autorisation précédemment configurée :

   cat >authz-policy.yaml <<EOF
   apiVersion: networking.gke.io/v1
   kind: GCPAuthzPolicy
   metadata:
     name: my-workload-authz
     namespace: NAMESPACE
   spec:
     targetRefs:
     - group: ""
       kind: Pod
       selector:
         matchLabels:
           app: EXAMPLE_APP
     rules:
     - from:
         sources:
         - principals:
           - principal:
               type: Exact
               value: "spiffe://cluster.local/NAMESPACE/pod1"
       to:
         operations:
         - paths:
           - type: Exact
             value: "/api/payments-schedule"
     action: CUSTOM
     enforcementLevel: L7
     customProviders:
       extensionRefs:
       - group: networking.gke.io
         kind: GCPAuthzExtension
         name: my-authz-ext
   EOF
   kubectl apply -f authz-policy.yaml
   

   Le résultat est semblable à :

   gcpauthzpolicy.networking.gke.io/my-workload-authz created
   

   Le proxy attend la réponse de l'extension d'autorisation avant de transférer la requête à l'application. Si l'extension rejette la requête en mettant fin à l'appel avec une erreur, ou si l'appel échoue ou expire alors que failOpen est défini sur false, l'appelant reçoit une réponse HTTP 500. Si l'extension envoie une réponse immédiate, l'appelant reçoit le code d'état de cette réponse.