Utiliser des contraintes de règles de sécurité Cloud Service Mesh

Policy Controller est fourni avec une bibliothèque par défaut de modèles de contrainte qui peuvent être utilisés avec le lot de règles de sécurité Cloud Service Mesh pour auditer la conformité des failles et des bonnes pratiques de sécurité de votre maillage.

Ce groupe de contraintes aborde et applique les règles dans les domaines suivants :

• Cloud Service Mesh applique le trafic mTLS
• Bonnes pratiques concernant les règles d'autorisation Cloud Service Mesh
• Application de la sécurité des charges de travail Cloud Service Mesh

Contraintes liées aux bundles de règles Cloud Service Mesh

Nom de la contrainte	Description de la contrainte	ID de commande
asm-policy-v0.0.1-asm-ingressgateway-label	N'applique le libellé ingressgateway d'Istio que sur les pods ingressgateway.	1.1.1
asm-policy-v0.0.1-asm-sidecar-injection	Applique le proxy side-car Istio, toujours injecté dans les pods de la charge de travail.	1.1.2
asm-policy-v0.0.1-asm-authz-policy-mesh-default-deny	Applique la règle de refus AuthorizationPolicy par défaut au niveau du maillage.	1.2.1
asm-policy-v0.0.1-asm-authz-policy-normalization	Applique la normalisation de la règle AuthorizationPolicy.	1.2.2
asm-policy-v0.0.1-asm-authz-policy-safe-pattern	Applique les modèles sécurisés de la règle AuthorizationPolicy.	1.2.3
asm-policy-v0.0.1-asm-peer-authn-mesh-strict-mtls	Applique PeerAuthentication en mode mTLS strict au niveau du maillage.	1.3.1
asm-policy-v0.0.1-asm-peer-authn-strict-mtls	L'application de l'ensemble des PeerAuthentications ne peut pas écraser le mode mTLS strict.	1.3.2
asm-policy-v0.0.1-asm-request-authn-prohibited-output-headers	Appliquez la règle jwtRules outputPayloadToHeader pour ne pas contenir d'en-têtes de requête HTTP connus	1.4.1

Profils de groupes

Dans le groupe de règles de sécurité Cloud Service Mesh, vous pouvez utiliser deux profils en fonction du niveau de rigueur. Le niveau de rigueur faible est associé à moins de contraintes, ce qui offre une plus grande flexibilité. Le niveau de rigueur élevé est soumis à davantage de contraintes, ce qui offre un contrôle plus sécurisé des règles.

Faible niveau de rigueur

Le profil de faible niveau de rigueur comporte les contraintes de règle suivantes :

• Le libellé istio:ingressgateway ne peut être utilisé que par les pods de la passerelle d'entrée Istio.

• Dans AuthorizationPolicy, vous ne pouvez utiliser les champs hosts ou notHosts qu'en sélectionnant la passerelle d'entrée Istio associée au libellé istio:ingressgateway.

• Dans AuthorizationPolicy, lorsque les champs methods ou notMethods sont utilisés, les valeurs doivent être en majuscules.

• Dans AuthorizationPolicy, lorsque le champ request.headers est utilisé, les valeurs ne peuvent pas contenir d'espaces.

• Dans AuthorizationPolicy, lorsque les champs paths ou notPaths sont utilisés, les valeurs doivent être normalisées.

Niveau de rigueur élevé

Le niveau de rigueur élevé inclut toutes les contraintes du niveau de rigueur faible, ainsi que les contraintes suivantes :

• Pour tous les pods de charge de travail, l'annotation sidecar.istio.io/inject: false ne peut pas être appliquée pour contourner l'injection du proxy.

• Une règle AuthorizationPolicy au niveau du maillage qui définit une règle de refus par défaut est appliquée.

• La règle AuthorizationPolicy doit suivre le modèle ALLOW-with-positive-matching ou DENY-with-negative-match.

• Dans AuthorizationPolicy, lorsque les champs hosts ou notHosts sont utilisés, les valeurs doivent être des paires de <host-name> et de <host-name>:*.

• Une règle PeerAuthentication au niveau du maillage qui définit le mode mTLS strict est appliquée.

• Pour toutes les règles PeerAuthentication du maillage, le mode mTLS ne peut être que UNSET ou STRICT, afin de suivre le mode mTLS strict.

Paramètres du groupe

Setter KPT	Description
strictness-level	Profil de niveau de rigueur du bundle Cloud Service Mesh, les options sont "Faible" ou "Élevé" (par défaut)

Avant de commencer

1. Installez et initialisez Google Cloud CLI, qui fournit les commandes gcloud et kubectl utilisées dans ces instructions. Si vous utilisez Cloud Shell, Google Cloud CLI est préinstallé.
2. Installez Policy Controller v1.11.2 ou version ultérieure sur votre cluster avec la bibliothèque par défaut de modèles de contraintes. Vous devez également activer la compatibilité avec les contraintes référentielles, car ce bundle contient des contraintes référentielles.
3. Vérifiez que Cloud Service Mesh est installé sur votre cluster.

Configurer Policy Controller pour les contraintes référentielles

Avertissement : Vous pouvez écraser vos propres modifications. Si vous disposez déjà d'un objet Config dans l'espace de noms gatekeeper-system, vous devez inclure tous les paramètres de personnalisation précédents pour conserver vos modifications.

1. Enregistrez le manifeste YAML suivant sous le nom policycontroller-config.yaml :

   apiVersion: config.gatekeeper.sh/v1alpha1
   kind: Config
   metadata:
     name: config
     namespace: "gatekeeper-system"
   spec:
     sync:
       syncOnly:
         - group: ""
           version: "v1"
           kind: "Namespace"
         - group: "security.istio.io"
           version: "v1beta1"
           kind: "AuthorizationPolicy"
         - group: "security.istio.io"
           version: "v1beta1"
           kind: "PeerAuthentication"
   

   Ce fichier manifeste configure Policy Controller pour surveiller des types d'objets spécifiques.

2. Appliquez le fichier manifeste policycontroller-config.yaml :

   kubectl apply -f policycontroller-config.yaml
   

Auditer le bundle de règles Cloud Service Mesh

Policy Controller vous permet d'appliquer des règles à votre cluster Kubernetes. Pour tester vos charges de travail et leur conformité avec les règles de sécurité Cloud Service Mesh décrites dans le tableau précédent, vous pouvez déployer ces contraintes en mode "audit" pour révéler les cas de non-respect et, plus important, vous donner la possibilité de les corriger avant de les appliquer à votre cluster Kubernetes.

Vous pouvez appliquer ces règles en définissant le paramètre spec.enforcementAction sur dryrun à l'aide de kpt ou de Config Sync.

kubectl

1. (Facultatif) Prévisualisez les contraintes de règle avec kubectl :

   kubectl kustomize https://github.com/GoogleCloudPlatform/gke-policy-library.git/bundles/asm-policy-v0.0.1
   

2. Appliquez les contraintes de règle avec kubectl :

   kubectl apply -k https://github.com/GoogleCloudPlatform/gke-policy-library.git/bundles/asm-policy-v0.0.1
   

   Le résultat est le suivant :

   asmauthzpolicydefaultdeny.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-authz-policy-mesh-default-deny created
   asmauthzpolicynormalization.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-authz-policy-normalization created
   asmauthzpolicysafepattern.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-authz-policy-safe-pattern created
   asmingressgatewaylabel.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-ingressgateway-label created
   asmpeerauthnmeshstrictmtls.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-peer-authn-mesh-strict-mtls created
   asmpeerauthnstrictmtls.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-peer-authn-strict-mtls created
   asmrequestauthnprohibitedoutputheaders.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-request-authn-prohibited-output-headers created
   asmsidecarinjection.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-sidecar-injection created
   

3. Vérifiez que les contraintes de règles ont été installées et si des cas de non-respect existent dans le cluster :

   kubectl get -k https://github.com/GoogleCloudPlatform/gke-policy-library.git/bundles/asm-policy-v0.0.1
   

   Le résultat ressemble à ce qui suit :

   NAME                                                                                                       ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   asmauthzpolicydefaultdeny.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-authz-policy-mesh-default-deny   dryrun               0
   
   NAME                                                                                                     ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   asmauthzpolicynormalization.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-authz-policy-normalization   dryrun               0
   
   NAME                                                                                                  ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   asmauthzpolicysafepattern.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-authz-policy-safe-pattern   dryrun               0
   
   NAME                                                                                          ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   asmingressgatewaylabel.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-ingressgateway-label   dryrun               0
   
   NAME                                                                                                     ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   asmpeerauthnmeshstrictmtls.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-peer-authn-mesh-strict-mtls   dryrun               0
   
   NAME                                                                                            ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   asmpeerauthnstrictmtls.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-peer-authn-strict-mtls   dryrun               0
   
   NAME                                                                                                                             ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   asmrequestauthnprohibitedoutputheaders.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-request-authn-prohibited-output-headers   dryrun               0
   
   NAME                                                                                    ENFORCEMENT-ACTION   TOTAL-VIOLATIONS
   asmsidecarinjection.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-sidecar-injection   dryrun               0
   

kpt

1. Installez et configurez kpt. kpt est utilisé dans ces instructions pour personnaliser et déployer les ressources Kubernetes.

2. Téléchargez le groupe de règles de sécurité Cloud Service Mesh à partir de GitHub à l'aide de kpt :

   kpt pkg get https://github.com/GoogleCloudPlatform/gke-policy-library.git/bundles/asm-policy-v0.0.1
   

3. Exécutez la fonction kpt set-enforcement-action pour définir l'action d'application des règles sur dryrun :

   kpt fn eval asm-policy-v0.0.1 -i gcr.io/kpt-fn/set-enforcement-action:v0.1 \
     -- enforcementAction=dryrun
   

4. Exécutez la fonction setter de kpt pour définir des champs spécifiques aux règles de sécurité Cloud Service Mesh :

   kpt fn eval asm-policy-v0.0.1 --image gcr.io/kpt-fn/apply-setters:v0.2.0 -- \
   strictness-level="Low"
   

5. Initialisez le répertoire de travail avec kpt, qui crée une ressource pour suivre les modifications :

   cd asm-policy-v0.0.1
   kpt live init
   

6. Appliquez les contraintes de règles avec kpt :

   kpt live apply
   

   Le résultat est le suivant :

   asmauthzpolicydefaultdeny.constraints.gatekeeper.sh/asm-authz-policy-mesh-default-deny created
   asmauthzpolicynormalization.constraints.gatekeeper.sh/asm-authz-policy-normalization created
   asmauthzpolicysafepattern.constraints.gatekeeper.sh/asm-authz-policy-safe-pattern created
   asmingressgatewaylabel.constraints.gatekeeper.sh/asm-ingressgateway-label created
   asmpeerauthnmeshstrictmtls.constraints.gatekeeper.sh/asm-peer-authn-mesh-strict-mtls created
   asmpeerauthnstrictmtls.constraints.gatekeeper.sh/asm-peer-authn-strict-mtls created
   asmsidecarinjection.constraints.gatekeeper.sh/asm-sidecar-injection created
   7 resource(s) applied. 7 created, 0 unchanged, 0 configured, 0 failed
   

7. Vérifiez que les contraintes de règles ont été installées et si des cas de non-respect existent dans le cluster :

   kpt live status --output table --poll-until current
   

   L'état CURRENT confirme l'installation correcte des contraintes.

Config Sync

1. Installez et configurez kpt. kpt est utilisé dans ces instructions pour personnaliser et déployer les ressources Kubernetes.

Les opérateurs qui utilisent Config Sync pour déployer des règles sur leurs clusters peuvent suivre ces instructions :

1. Accédez au répertoire de synchronisation pour Config Sync :

   cd SYNC_ROOT_DIR
   

   Remarque : Kpt v1.0.0-beta.17 et versions ultérieures créent automatiquement un fichier resourcegroup.yaml lors de live init, qui ne devrait pas être enregistré dans votre dépôt Config Sync. Si ce n'est pas déjà fait, ajoutez resourcegroup.yaml au fichier .gitignore de votre dépôt.

   Pour créer ou ajouter .gitignore avec resourcegroup.yaml, procédez comme suit :

   echo resourcegroup.yaml >> .gitignore
   

2. Créez un répertoire policies dédié :

   mkdir -p policies
   

3. Téléchargez le groupe de règles de sécurité Cloud Service Mesh à partir de GitHub à l'aide de kpt :

   kpt pkg get https://github.com/GoogleCloudPlatform/gke-policy-library.git/bundles/asm-policy-v0.0.1 policies/asm-policy-v0.0.1
   

4. Exécutez la fonction kpt set-enforcement-action pour définir l'action d'application des règles sur dryrun :

   kpt fn eval policies/asm-policy-v0.0.1 -i gcr.io/kpt-fn/set-enforcement-action:v0.1 -- enforcementAction=dryrun
   

5. Exécutez la fonction setter de kpt pour définir des champs spécifiques aux règles de sécurité de Cloud Service Mesh :

   kpt fn eval policies/asm-policy-v0.0.1 --image gcr.io/kpt-fn/apply-setters:v0.2.0 -- \
   strictness-level="Low"
   

6. (Facultatif) Prévisualisez les contraintes de règles à créer :

   kpt live init policies/asm-policy-v0.0.1
   kpt live apply --dry-run policies/asm-policy-v0.0.1
   

   Le résultat est le suivant :

   Dry-run strategy: client
   inventory update started
   inventory update finished
   apply phase started
   asmauthzpolicydefaultdeny.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-authz-policy-mesh-default-deny apply successful
   asmauthzpolicynormalization.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-authz-policy-normalization apply successful
   asmauthzpolicysafepattern.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-authz-policy-safe-pattern apply successful
   asmingressgatewaylabel.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-ingressgateway-label apply successful
   asmpeerauthnmeshstrictmtls.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-peer-authn-mesh-strict-mtls apply successful
   asmpeerauthnstrictmtls.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-peer-authn-strict-mtls apply successful
   asmrequestauthnprohibitedoutputheaders.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-request-authn-prohibited-output-headers apply successful
   asmsidecarinjection.constraints.gatekeeper.sh/asm-policy-v0.0.1-asm-sidecar-injection apply successful
   apply phase finished
   inventory update started
   inventory update finished
   apply result: 8 attempted, 8 successful, 0 skipped, 0 failed
   

7. Si votre répertoire de synchronisation pour Config Sync utilise Kustomize, ajoutez policies/asm-policy-v0.0.1 à votre fichier kustomization.yaml racine. Sinon, supprimez le fichier policies/asm-policy-v0.0.1/kustomization.yaml :

   rm SYNC_ROOT_DIR/policies/asm-policy-v0.0.1/kustomization.yaml
   

8. Transférez les modifications au dépôt Config Sync :

   git add SYNC_ROOT_DIR/policies/asm-policy-v0.0.1
   git commit -m 'Adding ASM security policy audit enforcement'
   git push
   

9. Vérifiez l'état de l'installation :

   watch gcloud beta container fleet config-management status --project PROJECT_ID
   

   L'état SYNCED confirme l'installation des règles .

Consulter les notifications de non-respect des règles

Une fois les contraintes de règle installées en mode audit, les cas de non-respect du cluster peuvent être visualisés dans l'interface utilisateur à l'aide du tableau de bord Policy Controller.

Vous pouvez également utiliser kubectl pour afficher les cas de non-respect sur le cluster à l'aide de la commande suivante :

kubectl get constraint -l policycontroller.gke.io/bundleName=asm-policy-v0.0.1 -o json | jq -cC '.items[]| [.metadata.name,.status.totalViolations]'

En cas de non-respect des règles, vous pouvez consulter la liste des messages de non-respect par contrainte avec :

kubectl get constraint -l policycontroller.gke.io/bundleName=asm-policy-v0.0.1 -o json | jq -C '.items[]| select(.status.totalViolations>0)| [.metadata.name,.status.violations[]?]'

Modifier l'action d'application du bundle de règles Cloud Service Mesh

Une fois que vous avez examiné les cas de non-respect des règles sur votre cluster, vous pouvez envisager de modifier le mode d'application afin que le contrôleur d'admission génère un avertissement (warn) ou bloque (deny) l'application des ressources non conformes sur le cluster.

Avertissement : la mesure coercitive deny doit être utilisée avec prudence, car elle peut potentiellement bloquer les modifications requises, ce qui entraînera une interruption des charges de travail critiques ou du cluster. Il est fortement recommandé de n'utiliser que les actions d'application warn ou dryrun sur les clusters comportant des charges de travail de production, lorsque vous testez de nouvelles contraintes ou effectuez des migrations telles que la mise à niveau de plates-formes. Pour en savoir plus sur les mesures d'application, consultez la section Effectuer un audit à l'aide de contraintes.

kubectl

1. Utilisez kubectl pour définir la mesure coercitive des règles sur warn :

   kubectl get constraint -l policycontroller.gke.io/bundleName=asm-policy-v0.0.1 -o name | xargs -I {} kubectl patch {} --type='json' -p='[{"op":"replace","path":"/spec/enforcementAction","value":"warn"}]'
   

2. Vérifiez que la mesure coercitive des contraintes de règle a été mise à jour :

   kubectl get constraint -l policycontroller.gke.io/bundleName=asm-policy-v0.0.1
   

kpt

1. Exécutez la fonction kpt set-enforcement-action pour définir la mesure coercitive des règles sur warn :

   kpt fn eval -i gcr.io/kpt-fn/set-enforcement-action:v0.1 -- enforcementAction=warn
   

2. Appliquez les contraintes de règles :

   kpt live apply
   

Config Sync

Les opérateurs qui utilisent Config Sync pour déployer des règles sur leurs clusters peuvent suivre ces instructions :

1. Accédez au répertoire de synchronisation pour Config Sync :

   cd SYNC_ROOT_DIR
   

2. Exécutez la fonction kpt set-enforcement-action pour définir la mesure coercitive des règles sur warn :

   kpt fn eval policies/asm-policy-v0.0.1 -i gcr.io/kpt-fn/set-enforcement-action:v0.1 -- enforcementAction=warn
   

3. Transférez les modifications au dépôt Config Sync :

   git add SYNC_ROOT_DIR/policies/asm-policy-v0.0.1
   git commit -m 'Adding ASM security policy bundle warn enforcement'
   git push
   

4. Vérifiez l'état de l'installation :

   gcloud alpha anthos config sync repo list --project PROJECT_ID
   

   Le dépôt qui s'affiche dans la colonne SYNCED confirme l'installation des règles.

Tester l'application des règles

Créez une ressource non conforme sur le cluster à l'aide de la commande suivante :

cat <<EOF | kubectl apply -f -
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: non-compliant-authz-policy
spec:
  action: ALLOW
  rules:
  - to:
    - operation:
        methods: ["get"]
EOF

Le contrôleur d'admission doit générer un avertissement répertoriant les cas de violation des règles que cette ressource ne respecte pas, comme indiqué dans l'exemple suivant :

Warning: [asm-policy-v0.0.1-asm-authz-policy-normalization] in rules-to-operation, methods or notMethods must be uppercase
authorizationpolicy.security.istio.io/non-compliant-authz-policy created

Supprimer le bundle de règles Cloud Service Mesh

Si nécessaire, le bundle de règles Cloud Service Mesh peut être supprimé du cluster.

kubectl

• Utilisez kubectl pour supprimer les règles :

  kubectl delete constraint -l policycontroller.gke.io/bundleName=asm-policy-v0.0.1
  

kpt

• Supprimez les règles :

  kpt live destroy
  

Config Sync

Les opérateurs qui utilisent Config Sync pour déployer des règles sur leurs clusters peuvent suivre ces instructions :

1. Transférez les modifications au dépôt Config Sync :

   git rm -r SYNC_ROOT_DIR/policies/asm-policy-v0.0.1
   git commit -m 'Removing Cloud Service Mesh  policies'
   git push
   

2. Vérifiez l'état :

   gcloud alpha anthos config sync repo list --project PROJECT_ID
   

   Le dépôt qui s'affiche dans la colonne SYNCED confirme la suppression des règles.