Configurez et testez kritis-validation-hook dans un cluster Container Service for Kubernetes (ACK) afin de bloquer les images de conteneur non signées lors de l'admission. Seules les images signées par une autorité de confiance sont autorisées, ce qui réduit les risques liés à l'exécution de code inattendu ou malveillant.
Prérequis
Vous disposez d'un cluster ACK managé ou d'un cluster ACK dédié (obsolète).
Contexte
kritis-validation-hook s'appuie sur le logiciel open source kritis, avec une intégration approfondie à Container Registry (ACR) et prend en charge la vérification des images de conteneur signées à l'aide de Key Management Service (KMS). Grâce à la collaboration entre Security Center, KMS et ACR, la signature et la vérification des images sont entièrement automatisées pour renforcer la sécurité de l'environnement d'exécution du cluster.
Consultez la rubrique Vérifier les signatures d'images de conteneur avec kritis-validation-hook.
Configurer les permissions d'accès aux ressources
Assurez-vous que le rôle RAM utilisé par le cluster dispose des permissions suivantes :
"cr:ListInstance",
"cr:ListMetadataOccurrences"
Pour les clusters ACK managés, accordez ces permissions au rôle RAM Worker. Pour les clusters ACK dédiés, accordez-les aux rôles RAM Master et Worker.
Ajoutez les permissions manquantes comme suit.
-
Créez une stratégie personnalisée avec le contenu suivant :
{ "Statement": [ { "Action": [ "cr:ListInstance", "cr:ListMetadataOccurrences" ], "Effect": "Allow", "Resource": "*" } ], "Version": "1" } -
Accordez la stratégie au rôle RAM Worker du cluster.
Pour les clusters ACK dédiés, accordez également la stratégie au rôle RAM Master.
Activer la vérification des signatures d'images
Cet exemple configure la vérification des signatures d'images pour le namespace default. La signature des images ne relève pas du périmètre de kritis-validation-hook ; cet exemple suppose que les images sont déjà signées. Consultez la rubrique Utiliser la signature d'images de conteneur pour connaître les étapes de signature.
L'exemple utilise les informations de signature suivantes. Remplacez les exemples de valeurs par vos valeurs réelles.
|
Informations de signature |
Exemple de valeur |
Comment l'obtenir |
Champ YAML |
|
Clé publique KMS (Base64) |
|
|
|
|
ID de clé KMS |
|
|
|
|
Nom du témoin (Witness) |
|
Configurer un témoin et une politique de vérification de signature |
|
|
Image signée |
|
— |
— |
Déclarer l'autorité de confiance
Créez le fichier AttestationAuthority.yaml avec le contenu suivant :
apiVersion: kritis.grafeas.io/v1beta1
kind: AttestationAuthority
metadata:
name: demo-aa
spec:
noteReference: namespaces/demo-aa
publicKeyData: LS0tLS1CRUdJTiBQ***
publicKeyId: key-4a2ef103-5aa3-4220-****
Appliquez la ressource.
kubectl apply -f AttestationAuthority.yaml
Créer une politique de vérification de signature
Créez le fichier GenericAttestationPolicy.yaml avec le contenu suivant. La politique fait référence à l'objet AttestationAuthority créé à l'étape précédente.
apiVersion: kritis.grafeas.io/v1beta1
kind: GenericAttestationPolicy
metadata:
name: demo-gap
spec:
attestationAuthorityNames:
- demo-aa
Appliquez la ressource.
kubectl apply -f GenericAttestationPolicy.yaml
Tester avec une image non signée
Déployez une image non signée.
kubectl create deployment test-denied --image=anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
Résultat attendu :
error: failed to create deployment: admission webhook "kritis-validation-hook-deployments.grafeas.io" denied the request: "ACROpenAPIError detail: <image anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6 is not attested because of get resource url for anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6: ListInstance failed, instanceName: "anolis", regionId: "cn-zhangjiakou", requstURL:error:****
Le webhook d'admission refuse le déploiement car l'image ne possède pas d'attestation valide provenant de demo-aa.
Tester avec une image signée
Déployez une image signée. Remplacez l'adresse de l'image par l'adresse réelle de l'image signée.
kubectl create deployment test-allow --image=kritis-demo***.cn-hangzhou.cr.aliyuncs.com/kritis-demo***/alpine@sha256:ddba4d27a7ffc3f86dd6c2f92041af252a1f23a8e742c90e6e1297bfa1bc0c45
Résultat attendu :
deployment.apps/test-allow created
Le déploiement aboutit car l'image est attestée par l'autorité de confiance demo-aa.
Configurer une liste d'autorisation pour la vérification des signatures d'images
Par défaut, kritis-validation-hook vérifie chaque image de conteneur située dans son périmètre d'application. Dans les environnements middleware ou de maillage de services, les sidecars injectés par des modules complémentaires tiers peuvent ne pas être signés, ce qui entraîne l'échec de la création des pods. Configurez une liste d'autorisation pour ignorer la vérification des signatures pour certaines images spécifiques.
Définissez une ressource admissionallowlists.kritis.grafeas.io pour spécifier les images qui doivent contourner la vérification.
apiVersion: kritis.grafeas.io/v1beta1 # Default value. Do not modify.
kind: AdmissionAllowlist # Default value. Do not modify.
metadata:
name: kritis-allowlist # Must be unique within the cluster.
spec:
patterns: # Define one or more allowlist entries.
- namePattern: 'registry*.*.aliyuncs.com/acs/*'
- namePattern: 'registry-vpc.cn-beijing.aliyuncs.com/arms-docker-repo/*'
namespace: 'default' # Optional. If omitted, the entry applies to all namespaces.
Règles de correspondance pour namePattern
Chaque valeur namePattern correspond à la référence complète de l'image, y compris l'hôte du registre, le chemin du dépôt et le tag ou le digest. Les règles de correspondance suivantes s'appliquent :
|
Règle |
Description |
Exemple |
|
Correspondance exacte |
Une valeur sans |
|
|
|
Correspond à n'importe quel caractère sauf |
|
|
|
Correspond aux lettres, chiffres, traits d'union ( |
|
Ajouter les images système ACK à la liste d'autorisation
-
Créez le fichier
kritis-admission-allowlist-acs.yamlavec le contenu suivant :apiVersion: kritis.grafeas.io/v1beta1 kind: AdmissionAllowlist metadata: name: allow-acs-images spec: patterns: - namePattern: 'registry*.*.aliyuncs.com/acs/*' - namePattern: 'registry-*.ack.aliyuncs.com/acs/*'Modèles courants de liste d'autorisation :
# Images used by ACK - namePattern: 'registry*.*.aliyuncs.com/acs/*' - namePattern: 'registry-*.ack.aliyuncs.com/acs/*' # Images used by ACK (China regions only) - namePattern: 'registry*.cn-*.aliyuncs.com/acs/*' - namePattern: 'registry-cn-*.ack.aliyuncs.com/acs/*' # Images used by ARMS - namePattern: 'registry*.*.aliyuncs.com/arms-docker-repo/*' # Images used by ARMS (China regions only) - namePattern: 'registry*.cn-*.aliyuncs.com/arms-docker-repo/*' -
Appliquez la liste d'autorisation.
kubectl apply -f kritis-admission-allowlist-acs.yamlRésultat attendu :
admissionallowlist.kritis.grafeas.io/allow-acs-images created -
Vérifiez la liste d'autorisation :
kubectl get admissionallowlists.kritis.grafeas.ioRésultat attendu :
NAME AGE allow-acs-images 2m22s