Un guide étape par étape pour utiliser Secret Manager avec GKE et CSI Driver

Introduction

La gestion des informations sensibles telles que les clés API, les informations d’identification et les secrets de configuration consiste à développer des applications Skylands sûres et fiables. Dans Google Cloud Ecosystème, Secret Manager fournit un moyen centralisé et sûr d’économiser, d’accéder et de gérer ces secrets. Lors de l’exécution des applications sur Google Kubernetes Engine (GKE), y compris le Secret Manager garantit que vos charges de travail sont en mesure d’accéder à des secrets en toute sécurité sans avoir à les coder dur dans vos conteneurs ou votre base de code.

Objectif : –

L’objectif de ce blog est de fournir un guide complet sur la mise en œuvre du Secret Manager à l’aide du fournisseur de coefficient de clé GCP pour le pilote d’interface de stockage de conteneurs Secrets Store (CSI) dans un cluster Google Kubernetes Engine (GKE). Grâce à ce blog, nous comprendrons l’intégration des gestionnaires secrets dans Google Kubernetes Engine en gérant et en accédant solidement aux informations sensibles, telles que Secret et les informations d’identification dans GKE.

Gérer les secrets par le cadre de Secret Manager

Qu’est-ce que le directeur secret?

Secret Manager est un service sécurisé et centralisé sur Google Cloud conçu pour stocker des informations sensibles telles que les clés d’API, les mots de passe et les certificats. Il simplifie la gestion, l’accès et l’audit des secrets dans votre environnement cloud, vous aidant à garder les données critiques en sécurité et organisées.

Pourquoi utiliser Secret Manager?

1. Sécurité: Les secrets sont cryptés au repos à l’aide de clés gérées par Google ou gérées par le client (CMEK).
2. Gestion secrète centralisée: Google Cloud Secret Manager stocke en toute sécurité les secrets.
3. Contrôle d’accès basé sur l’identité de la charge de travail: Les charges de travail GKE peuvent accéder à des secrets en toute sécurité sans les touches de compte de service en utilisant l’identité de la charge de travail.
4. Versioning et rotation: Il a le versioning, vous pouvez donc mettre à jour et faire reculer en toute sécurité.
5. Intégration avec les pipelines CI / CD: S’intègre de manière transparente à Cloud Build, aux actions GitHub ou à d’autres CI / CD pour injecter des secrets pendant le déploiement ou la construction.

Configuration du gestionnaire secret : –

1. Créez un cluster GKE: – Créez un cluster GKE via Console, Terraform ou par CLI.

Cluster GKE

2. Allumez le module complémentaire Secret Manager: – Assurez-vous d’activer le module complémentaire Secret Manager lors de la configuration d’un cluster GKE.Acsez-vous les secrets conservés dans Secret Manager car les volumes sont montés dans des pods Kubernetes en utilisant le module complémentaire Secret Manager.

GKE CLUSTER ADD-WE

3. Vérifiez qu’après l’activation de l’installation du pilote CSI Secrets Secrets Secrets Store: – Vérifiez que l’installation est terminée à l’aide de la commande kubectl get pods, qui répertorie tous les pods avec les étiquettes CSI-secrets-store-gke et csi-secrets-store-provider-gke dans l’espace de noms du système Kube.

CSI Secret Pods

4. Créez des secrets dans un gestionnaire secret: – Un gestionnaire secret a été créé à l’aide de la console GCP pour se prémunir contre un accès indésirable et stocker en toute sécurité des informations privées comme les mots de passe et les clés d’API. Pour gérer efficacement les mises à jour et préserver une histoire sûre de modifications, des versions secrètes sont effectuées.

Secrets in Secret Manager

Version secrète

5. Créez une classe de fournisseurs secrètes: – Pour spécifier comment les secrets du Secret Manager sont accessibles et montés dans vos pods Kubernetes, créez une SecretProviderClass en utilisant le YAML ci-dessous.

Secretproviderclass.yaml :-

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
name: dev-secret-provider
namespace: dev
spec:
provider: gke
parameters:
secrets: |
- resourceName: "projects/954514138689/secrets/DB_USER/versions/1"
fileName: "DB_USER"
- resourceName: "projects/954514138689/secrets/DB_PASSWORD/versions/1"
fileName: "DB_PASSWORD"

secretObjects:
- secretName: dev-secrets
type: Opaque
data:
- objectName: "DB_USER"
key: "DB_USER"
- objectName: "DB_PASSWORD"
key: "DB_PASSWORD"

6. Appliquer le SecretProviderClass Yaml: – Appliquez le SecretProviderClass YAML en utilisant la commande suivante dans GKE.

kubectl apply -f secretproviderclass.yaml

Note :-
1.Anse n’a pas besoin de créer un objet secret K8S séparément. Il sera créé automatiquement lorsque vous créez une pod avec le volume du pilote CSI.
2. Le bloc SecretObjects dans le YAML ci-dessus est facultatif et n’est nécessaire que si vous avez besoin de synchroniser le contenu monté avec un secret de Kubernetes. Vous obtiendrez toujours l’objet Secret Manager monté sur le pod si vous n’utiliserez pas ce bloc.

6. Donnez la permission au conducteur CSI: – Donnez l’autorisation au magasin de secrets du conducteur CSI d’utiliser les rôles de cluster et la liaison des rôles de cluster pour générer des secrets GKE.

Secret-store-rbac.yaml:-

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: secrets-store-csi-secrets-access
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list", "watch", "create", "patch"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: secrets-store-csi-secrets-access-binding
subjects:
- kind: ServiceAccount
  name: secrets-store-csi-driver-gke
  namespace: kube-system
roleRef:
kind: ClusterRole
name: secrets-store-csi-secrets-access
apiGroup: rbac.authorization.k8s.io

7. Définissez une variable d’environnement pour référencer les secrets de Kubernetes: – Créez un déploiement.yaml pour GKE et transmettez la référence des secrets GKE et du volume de montage sur le déploiement.yaml.
Vous trouverez ci-dessous un exemple du déploiement.

Exemple de déploiement GKE.yaml

8. Créer le fichier de service: – Créez un fichier Service.yaml pour exposer votre déploiement et permettez à l’accès réseau à l’application et appliquez-les à l’aide des commandes.

service.yaml

Kubectl apply  -f deployment.yaml
Kubectl apply  -f service.yaml

9. Vérifiez les secrets GKE: – Après avoir appliqué le service et le déploiement, vérifiez que le pilote CSI a créé les secrets GKE ou ne pas utiliser la commande suivante.

Kubectl get secrets -n dev

Secrets de Kubernetes

Conclusion : –

En conclusion, le maintien de la sécurité et de l’intégrité de vos applications de moteur Google Kubernetes dépend fortement d’une gestion secrète efficace. Les organisations peuvent réduire considérablement le risque d’exposition aux données sensibles en utilisant les fonctionnalités intégrées de GKE, comme Kubernetes Secrets, et en intégrant des programmes fiables comme Google Cloud Secret Manager. Les développeurs et les équipes d’opérations peuvent créer et mettre en œuvre des applications sécurisées et résilientes dans l’environnement GKE avec confiance si les stratégies discutées sont mises en pratique, de la création et de la distribution secrètes appropriées aux solides contrôles d’accès et à la rotation fréquente.

Vous avez trouvé cela utile? PARTAGEZ-LE