Configurer Service Security sur le maillage de services side-car Envoy sur GKE

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

Prérequis

Pour commencer, nous partons du principe que vous avez déjà:

Configurer des stratégies d'autorisation sur les sidecars sur GKE

Cette section explique comment configurer différents types de stratégies d'autorisation sur les sidecars Cloud Service Mesh sur GKE.

Avant de pouvoir créer une règle d'autorisation, vous devez installer la CustomResourceDefinition (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 permettent de 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 stratégie d'autorisation.

Stratégie d'autorisation pour refuser toutes les requêtes

Si une charge de travail ne doit effectuer que des appels sortants, comme une tâche cron, vous pouvez configurer une règle d'autorisation pour refuser toutes les requêtes HTTP entrantes vers la charge de travail. L'exemple suivant refuse les requêtes HTTP entrantes vers la charge de travail whereami.

Pour créer et appliquer la stratégie 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: wherami
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 à des critères spécifiques tout en rejetant le reste. L'exemple suivant configure une stratégie d'autorisation sur le déploiement whereami pour n'autoriser que les requêtes mTLS provenant des pods avec l'identité spiffee://cluster.local/ns1/pod1.

Pour créer et appliquer la règle d'autorisation d'accès, 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:
- from:
    sources:
    - principals:
      - type: Exact
        value: "spiffee://cluster.local/ns1/pod1"
action: ALLOW
EOF

  2. Appliquez la règle :

    kubectl apply -f allow-authz-policy.yaml

Stratégie d'autorisation pour refuser les requêtes en fonction de règles

L'exemple suivant refuse les requêtes HTTP POST entrantes vers la charge de travail whereami lorsqu'elle se trouve sur le chemin d'accès /admin .

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

  1. Créez une stratégie 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: ["POST"]
action: DENY
EOF

  2. Appliquez la règle :

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