Configurer la sécurité du service 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 GKE.
Prérequis
Pour commencer, ce guide suppose que vous avez déjà:
- Vous avez créé un cluster GKE et l'avez enregistré dans un parc.
- Configurez un maillage de services side-car Envoy avec les API Gateway.
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 peuvent appliquer un contrôle des accès au trafic entrant dans les sidecars 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 job 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:
Créez une stratégie 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
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 stratégie d'autorisation qui n'autorise que les requêtes qui répondent à des critères spécifiques, tout en rejetant les autres. L'exemple suivant configure une règle d'autorisation sur whereami
, où seules les requêtes GET
contenant l'en-tête HTTP x-user-role:admin
sont autorisées.
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 :
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
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 GET
entrantes à la charge de travail whereami
lorsqu'elles se trouvent sur le chemin /admin
.
Pour créer et appliquer la stratégie d'autorisation de refus, procédez comme suit:
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: ["GET"] action: DENY EOF
Appliquez la règle :
kubectl apply -f deny-path-authz-policy.yaml