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 de stockage natives AWS différentes que vous pouvez utiliser avec Kubernetes : EBS, EFS et pour Lustre. FSx Tous les trois proposent un chiffrement au repos à l'aide d'une clé gérée par le service ou d'une clé principale du client (CMK). Pour EBS, vous pouvez utiliser le pilote de stockage intégré ou le pilote EBS CSI. Les deux incluent des paramètres permettant de chiffrer les volumes et de fournir une clé CMK. Pour EFS, vous pouvez utiliser le pilote EFS CSI, mais contrairement à EBS, le pilote EFS CSI ne prend pas en charge le provisionnement dynamique. Si vous souhaitez utiliser EFS avec EKS, vous devez fournir 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. Outre le chiffrement au repos, EFS et FSx 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 le service par défaut, bien qu'il soit possible de fournir votre propre clé 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>

Chiffrer 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 pivoter CMKs votre

Configurez KMS pour qu'il fasse automatiquement pivoter votre CMKs. Cela fera pivoter 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, voir 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 fichiers 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, consultez le https://docs.aws.amazon.com/efs/latest/ug/efsfichier -access-points.html. Aujourd'hui, si vous souhaitez utiliser un point d'accès (AP), vous devez référencer le point d'accès dans les volumeHandle paramètres 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. Ils sont conservés 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 un objet secret Kubernetes en faisant référence au 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, consultez https://kubernetes. io/docs/concepts/configuration/secret/.

Utiliser AWS KMS pour le chiffrement de l'enveloppe des secrets Kubernetes

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

Auditez 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 de 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 fait pas automatiquement pivoter 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 des 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 sous forme de volumes sont instanciés sous forme de volumes tmpfs (un système de fichiers sauvegardé par de la 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. Ces services offrent des fonctionnalités telles que des contrôles d'accès précis, un cryptage renforcé 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 le 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 des secrets scellés en toute sécurité dans des systèmes de contrôle de source tels que Git. Consultez Gérer le déploiement des secrets dans Kubernetes à l'aide de Sealed Secrets pour plus d'informations.

À mesure que l'utilisation de magasins de secrets externes s'est accrue, le besoin de les intégrer à Kubernetes s'est accru. Le pilote CSI Secret Store est un projet communautaire qui utilise le modèle du 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 à la fois AWS Secrets Manager et AWS Parameter Store. Il peut également être configuré pour alterner les secrets lorsqu'ils expirent et pour synchroniser les secrets d'AWS Secrets Manager avec ceux de Kubernetes. 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 avec différents backends, notamment AWS Secrets Manager. La différence est qu'au lieu de récupérer des secrets dans 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 de manière native à Kubernetes.

Outils et ressources