Configurer la sécurité des services sur un maillage de services side-car Envoy sur GKE

Cette page explique comment configurer les fonctionnalités de sécurité sur un maillage de services side-car Envoy sur GKE.

Prérequis

Pour commencer, ce guide suppose que vous avez déjà :

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

Cette section vous explique comment configurer différents types de règles d'autorisation sur les side-cars Cloud Service Mesh sur GKE.

Avant de pouvoir créer une règle d'autorisation, vous devez installer la définition de ressource personnalisée (CRD) GCPAuthzPolicy :

curl https://github.com/GoogleCloudPlatform/gke-networking-recipes/blob/main/gateway-api/config/mesh/crd/experimental/gcpauthzpolicy.yaml \
| kubectl apply -f -

Les règles d'autorisation peuvent appliquer le contrôle des accès au trafic entrant dans les side-cars Envoy. Les règles peuvent être appliquées aux déploiements Kubernetes. Le déploiement doit se trouver dans le même espace de noms que la règle d'autorisation.

Règle d'autorisation pour refuser toutes les requêtes

Lorsque vous avez une charge de travail qui ne doit effectuer que des appels sortants, comme un job cron, vous pouvez configurer une règle d'autorisation pour refuser toute requête HTTP entrante à la charge de travail. L'exemple suivant refuse les requêtes HTTP entrantes à la charge de travail whereami.

Pour créer et appliquer la règle d'autorisation de refus, procédez comme suit :

  1. Créez une règle de refus en créant un fichier nommé deny-all-authz-policy.yaml :

    cat >deny-all-authz-policy.yaml <<EOF
    apiVersion: networking.gke.io/v1
    kind: GCPAuthzPolicy
    metadata:
      name: myworkload-authz
      namespace: sidecar-example
    spec:
    targetRefs:
    - kind: Deployment
      name: whereami
    httpRules:
    - to:
        operations:
        - paths:
          - type: Prefix
            value: "/"
    action: DENY
    EOF
    
  2. Appliquez la règle :

    kubectl apply -f deny-all-authz-policy.yaml
    

Règle d'autorisation pour autoriser les requêtes

Vous pouvez également configurer une règle d'autorisation qui n'autorise que les requêtes correspondant à un critère spécifique et rejette les autres. L'exemple suivant configure une règle d'autorisation sur whereami où seules les requêtes GET qui comportent l'en-tête HTTP x-user-role:admin dans la requête seront autorisées.

Pour créer et appliquer la règle d'autorisation "Autoriser", procédez comme suit. Supprimez la règle de refus créée précédemment avant d'ajouter cette règle pour voir les résultats :

  1. Créez une règle personnalisée en créant un fichier nommé allow-authz-policy.yaml :

    cat >allow-authz-policy.yaml <<EOF
    apiVersion: networking.gke.io/v1
    kind: GCPAuthzPolicy
    metadata:
      name: myworkload-authz
      namespace: sidecar-example
    spec:
    targetRefs:
    - kind: Deployment
      name: whereami
    httpRules:
    - to:
        operations:
        - methods: ["GET"]
      when: "request.headers['x-user-role'] == 'admin'
    action: ALLOW
    EOF
    
  2. Appliquez la règle :

    kubectl apply -f allow-authz-policy.yaml
    

Règle d'autorisation pour refuser les requêtes en fonction de règles

L'exemple suivant refuse les requêtes HTTP GET entrantes à la charge de travail whereami lorsqu'elle se trouve sur le chemin /admin .

Pour créer et appliquer la règle d'autorisation de refus, procédez comme suit :

  1. Créez une règle de refus en créant un fichier nommé deny-path-authz-policy.yaml :

    cat >deny-path-authz-policy.yaml <<EOF
    apiVersion: networking.gke.io/v1
    kind: GCPAuthzPolicy
    metadata:
      name: myworkload-authz
      namespace: sidecar-example
    spec:
    targetRefs:
    - kind: Deployment
      name: whereami
    httpRules:
    - to:
        operations:
        - paths:
          - type: Prefix
            value: "/admin"
          methods: ["GET"]
    action: DENY
    EOF
    
  2. Appliquez la règle :

    kubectl apply -f deny-path-authz-policy.yaml