Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Chiffrement des données et gestion des secrets

Chiffrement au repos

Il existe trois options AWS-native de stockage différentes que vous pouvez utiliser avec Kubernetes : EBS, EFS et FSx for Lustre. Les trois proposent un chiffrement au repos à l'aide d'une clé gérée par service ou d'une clé principale client (CMK). Pour EBS, vous pouvez utiliser le pilote de stockage intégré à l'arborescence ou le pilote EBS CSI. Les deux incluent des paramètres pour le chiffrement des volumes et la fourniture d'une CMK. Pour EFS, vous pouvez utiliser le pilote EFS CSI. Toutefois, contrairement à EBS, le pilote EFS CSI ne prend pas en charge le provisionnement dynamique. Si vous souhaitez utiliser EFS avec EKS, vous devez provisionner et configurer le chiffrement au repos pour le système de fichiers avant de créer un PV. Pour plus d'informations sur le chiffrement des fichiers EFS, reportez-vous à la section Chiffrement des données au repos. En plus d'offrir un chiffrement au repos, EFS et FSx pour Lustre incluent une option de chiffrement des données en transit. FSx for Lustre le fait par défaut. Pour EFS, vous pouvez ajouter le chiffrement du transport en ajoutant le tls paramètre à mountOptions dans votre PV, comme dans cet exemple :

apiVersion: v1
kind: PersistentVolume
metadata:
  name: efs-pv
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: efs-sc
  mountOptions:
    - tls
  csi:
    driver: efs.csi.aws.com
    volumeHandle: <file_system_id>

Le pilote FSx CSI prend en charge le provisionnement dynamique des systèmes de fichiers Lustre. Il chiffre les données à l'aide d'une clé gérée par service par défaut, bien qu'il soit possible de fournir votre propre CMK, comme dans cet exemple :

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: fsx-sc
provisioner: fsx.csi.aws.com
parameters:
  subnetId: subnet-056da83524edbe641
  securityGroupIds: sg-086f61ea73388fb6b
  deploymentType: PERSISTENT_1
  kmsKeyId: <kms_arn>

Chiffrez les données au repos

Le chiffrement des données au repos est considéré comme une bonne pratique. Si vous ne savez pas si le chiffrement est nécessaire, chiffrez vos données.

Faites une rotation périodique de vos CMK

Configurez KMS pour effectuer une rotation automatique de vos CMK. Cela permettra de changer vos clés une fois par an tout en sauvegardant les anciennes clés indéfiniment afin que vos données puissent toujours être déchiffrées. Pour plus d'informations, consultez la section Rotation des clés principales du client.

Utilisez les points d'accès EFS pour simplifier l'accès aux ensembles de données partagés

Si vous avez partagé des ensembles de données avec différentes autorisations de fichier POSIX ou si vous souhaitez restreindre l'accès à une partie du système de fichiers partagé en créant différents points de montage, pensez à utiliser des points d'accès EFS. Pour en savoir plus sur l'utilisation des points d'accès, voir https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html. Aujourd'hui, si vous souhaitez utiliser un point d'accès (AP), vous devez référencer l'AP dans le volumeHandle paramètre du PV.

Gestion des secrets

Les secrets Kubernetes sont utilisés pour stocker des informations sensibles, telles que des certificats utilisateur, des mots de passe ou des clés d'API. Elles sont conservées dans etcd sous forme de chaînes codées en base64. Sur EKS, les volumes EBS pour les nœuds etcd sont chiffrés avec le chiffrement EBS. Un pod peut récupérer les objets secrets d'un Kubernetes en référençant le secret dans le. podSpec Ces secrets peuvent être mappés à une variable d'environnement ou montés en tant que volume. Pour plus d'informations sur la création de secrets, voir https://kubernetes.io/docs/concepts/configuration/secret/.

Utiliser AWS KMS pour le chiffrement des enveloppes des secrets Kubernetes

Cela vous permet de chiffrer vos secrets à l'aide d'une clé de chiffrement de données unique (DEK). Le DEK est ensuite chiffré à l'aide d'une clé de chiffrement (KEK) d'AWS KMS qui peut être modifiée automatiquement selon un calendrier récurrent. Avec le plugin KMS pour Kubernetes, tous les secrets Kubernetes sont stockés dans etcd en texte chiffré au lieu de texte brut et ne peuvent être déchiffrés que par le serveur API Kubernetes. Pour plus de détails, consultez la section Utilisation de la prise en charge du fournisseur de chiffrement EKS pour une défense approfondie

Auditer l'utilisation de Kubernetes Secrets

Sur EKS, activez la journalisation des audits et créez un filtre de CloudWatch métriques et une alarme pour vous avertir lorsqu'un secret est utilisé (facultatif). Voici un exemple de filtre de métriques pour le journal d'audit Kubernetes. {($.verb="get") && ($.objectRef.resource="secret")} Vous pouvez également utiliser les requêtes suivantes avec CloudWatch Log Insights :

fields @timestamp, @message
| sort @timestamp desc
| limit 100
| stats count(*) by objectRef.name as secret
| filter verb="get" and objectRef.resource="secrets"

La requête ci-dessus affichera le nombre de fois qu'un secret a été consulté au cours d'une période donnée.

fields @timestamp, @message
| sort @timestamp desc
| limit 100
| filter verb="get" and objectRef.resource="secrets"
| display objectRef.namespace, objectRef.name, user.username, responseStatus.code

Cette requête affichera le secret, ainsi que l'espace de noms et le nom d'utilisateur de l'utilisateur qui a tenté d'accéder au secret et le code de réponse.

Faites régulièrement alterner vos secrets

Kubernetes ne change pas automatiquement les secrets. Si vous devez alterner les secrets, pensez à utiliser un magasin de secrets externe, par exemple Vault ou AWS Secrets Manager.

Utilisez des espaces de noms distincts pour isoler les secrets de différentes applications

Si vous avez des secrets qui ne peuvent pas être partagés entre les applications d'un espace de noms, créez un espace de noms distinct pour ces applications.

Utiliser des montages de volume plutôt que des variables d'environnement

Les valeurs des variables d'environnement peuvent apparaître involontairement dans les journaux. Les secrets montés en tant que volumes sont instanciés en tant que volumes tmpfs (un système de fichiers sauvegardé par RAM) qui sont automatiquement supprimés du nœud lorsque le pod est supprimé.

Utiliser un fournisseur de secrets externe

Il existe plusieurs alternatives viables à l'utilisation des secrets Kubernetes, notamment AWS Secrets Manager et Hashicorp's Vault. https://www.hashicorp.com/blog/injecting-vault-secrets-into-kubernetes-pods-via-a-sidecar/ Ces services offrent des fonctionnalités telles que des contrôles d'accès précis, un cryptage robuste et une rotation automatique des secrets qui ne sont pas disponibles avec Kubernetes Secrets. Les secrets scellés de Bitnami sont une autre approche qui utilise un cryptage asymétrique pour créer des « secrets scellés ». Une clé publique est utilisée pour chiffrer le secret tandis que la clé privée utilisée pour le déchiffrer est conservée dans le cluster, ce qui vous permet de stocker en toute sécurité des secrets scellés dans des systèmes de contrôle de source tels que Git. Consultez la section Gestion du déploiement de secrets dans Kubernetes à l'aide de secrets scellés pour plus d'informations.

À mesure que l'utilisation de magasins de secrets externes s'est développée, la nécessité de les intégrer à Kubernetes s'est accrue. Le pilote CSI Secret Store est un projet communautaire qui utilise le modèle de pilote CSI pour récupérer des secrets dans des magasins de secrets externes. Actuellement, le pilote prend en charge AWS Secrets Manager, Azure, Vault et GCP. Le fournisseur AWS prend en charge AWS Secrets Manager et AWS Parameter Store. Il peut également être configuré pour alterner les secrets lorsqu'ils expirent et pour synchroniser les secrets AWS Secrets Manager avec Kubernetes Secrets. La synchronisation des secrets peut être utile lorsque vous devez référencer un secret en tant que variable d'environnement au lieu de le lire à partir d'un volume.

Pour plus d'informations sur le fournisseur de secrets et de configuration AWS (ASCP), consultez les ressources suivantes :

external-secrets est une autre façon d'utiliser un magasin de secrets externe avec Kubernetes. À l'instar du pilote CSI, external-secrets fonctionne sur différents backends, y compris AWS Secrets Manager. La différence est qu'au lieu de récupérer des secrets depuis le magasin de secrets externe, external-secrets copie les secrets de ces backends vers Kubernetes en tant que secrets. Cela vous permet de gérer les secrets à l'aide de votre magasin de secrets préféré et d'interagir avec les secrets d'une Kubernetes-native manière ou d'une autre.

Outils et ressources