Configurer des règles d'autorisation sur des 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 règles 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 procéder comme suit :

Connectez-vous à votre Google Cloud compte. Si vous n'avez jamais utilisé Google Cloud, créez un compte pour évaluer les performances de nos produits dans des scénarios réels. 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.

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.

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

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 à 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:
  - kind: Pod
    selector: {}
  rules:
  - to:
      operations:
      - paths:
        - type: Prefix
          value: "/bad_token"
  action: DENY
EOF
kubectl apply -f ns-authz-policy-deny.yaml

Notez que le 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 à 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:
  - kind: Pod
    selector: {}
  rules:
  - to:
      operations:
      - paths:
        - type: Prefix
          value: "/headers"
        methods: ["GET"]
  action: ALLOW
EOF
kubectl apply -f ns-authz-policy-allow.yaml

Notez que le selector: {} vide cible tous les pods de l'espace de noms.

Refuser les requêtes entrantes à une charge de travail

Si vous disposez d'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 à 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:
 - kind: Pod
   selector:
matchLabels:
      app: EXAMPLE_APP
  rules:
  - to:
      operations:
      - paths:
        - type: Prefix
          value: "/deny_path"
  action: DENY
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 au chemin /deny_path sur les pods correspondant à l'application EXAMPLE_APP sera refusée et l'appelant recevra un code de réponse HTTP 403 Interdit.

Autoriser des requêtes entrantes spécifiques à 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 refusant 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:
 - kind: Pod
   selector:
matchLabels:
      app: EXAMPLE_APP
  rules:
  - from:
      sources:
      - principals:
        - principal:
          exact: "spiffe://cluster.local/NAMESPACE/pod1"
  action: ALLOW
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 refusée par le proxy avec un code HTTP 403 Interdit.

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

Vous pouvez apporter 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 le CRD GCPAuthzExtension s'il n'est pas déjà installé :

   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 ext_proc gRPC 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: ns1
   spec:
     backendRef:
       kind: Service
       name: authz-service
     loadBalancingScheme: INTERNAL_SELF_MANAGED
     forwardHeaders:
     - Authorization
     failOpen: false
     timeout: "0.1s"
     wireFormat: EXT_PROC_GRPC
   EOF
   kubectl apply -f authz-extension.yaml
   

   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:
     - kind: Pod
       selector:
         matchLabels:
           app: EXAMPLE_APP
     rules:
     - from:
         sources:
         - principals:
           - principal:
               exact: "spiffe://cluster.local/NAMESPACE/pod1"
       to:
         operations:
         - paths:
           - type: Exact
             value: "/api/payments-schedule"
     action: CUSTOM
     customProvider:
       authzExtension:
         targetRefs:
         - 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 attendra que votre service personnalisé renvoie une réponse OK ou DENY avant de transférer la requête à l'application ou de renvoyer un code HTTP 403 à l'appelant.