Le stockage d'objets de l'appliance Google Distributed Cloud (GDC) sous air gap est fourni par OTS (ONTAP Select). OTS dispose de son propre système de gestion des utilisateurs du stockage d'objets. Chaque identifiant d'utilisateur de stockage d'objets OTS est stocké en tant que secret dans les clusters.
Ce document décrit la procédure à suivre pour alterner les identifiants utilisateur du stockage d'objets OTS. Faites alterner les identifiants utilisateur de l'espace de stockage d'objets dans les situations suivantes :
- une rotation des clés planifiée régulièrement pour alterner toutes les clés utilisateur.
- atténuer l'exposition des clés. Vous devez faire tourner la clé utilisateur exposée dès que possible.
Avant de commencer
Procédez comme suit :
- Vérifiez que vous remplissez les conditions préalables concernant les ordinateurs portables.
- Assurez-vous de pouvoir vous connecter au cluster OTS et d'exécuter les commandes de la CLI
vserver object-store-server. - Assurez-vous de pouvoir vous connecter en tant qu'administrateur aux clusters d'infrastructure et de gestion à l'aide de
kubectl.
UID de traduction
Chaque utilisateur de stockage d'objets dispose d'une clé d'accès et d'une clé secrète stockées en tant que secret Kubernetes et utilisées par les charges de travail Kubernetes pour accéder au stockage d'objets backend. La rotation des clés utilisateur inclut la mise à jour de tous les secrets.
Vous pouvez obtenir la liste des utilisateurs du stockage d'objets en vous connectant à l'un des trois nœuds à l'aide de la commande suivante :
vserver object-store-server user show
Le résultat est une liste d'UID qui devrait ressembler à ceci :
[
"root",
"k8ssa_gpc-system_inventory-export-images",
"k8ssa_gpc-system_inventory-export-hardware",
"k8su_test-user@example.com"
]
Il existe trois types d'utilisateurs :
| UID | Type d'utilisateur | Nom du secret | Espace de noms secret |
|---|---|---|---|
| racine | Administrateur système | objectstorage-tenant-bucket-controller-standard-system-s3-sa | gpc-system |
| objectstorage-tenant-bucket-controller-standard-user-s3-sa | |||
| objectstorage-tenant-bucket-controller-nearline-user-s3-sa | |||
| k8ssa_<namespace>_<sa> | Compte de service Kubernetes | object-storage-key-std-sa-<encoded-sa> | <namespace> |
| k8su_<username> | Utilisateur Kubernetes | object-storage-key-std-user-<encoded-username> | object-storage-access-keys |
L'utilisateur root dispose de trois secrets identiques, ce qui reflète la structure du Data Center, qui englobe plusieurs classes de stockage et catégories de locataires. En revanche, Appliance ne propose qu'un seul niveau de stockage d'objets. Les trois secrets associés à l'utilisateur racine doivent être permutés simultanément.
L'identification de l'utilisateur (UID), à l'exception de l'utilisateur root, doit respecter le format k8ssa_<namespace>_<sa> ou k8su_<username>. Obtenez <encoded-sa> ou <encoded-username> :
echo -n 'UID_SUFFIX' | shasum -a 256 | cut -d " " -f 1 | xxd -r -p | base32 | awk '{print tolower($0)}' | sed 's/=*$//g'
Remplacez UID_SUFFIX par <sa> dans l'UID pour obtenir <encoded-sa>.
Remplacez UID_SUFFIX par <username> dans l'UID pour obtenir <encoded-username>.
Alterner la clé utilisateur
Connectez-vous au cluster OTS.
Obtenez la liste des UID des utilisateurs du stockage d'objets.
vserver object-store-server user showLe résultat est une liste d'UID. Vous trouverez des exemples dans Translate UID. Répétez les étapes suivantes pour chaque UID de la liste.
Obtenez l'ancienne clé d'accès et l'ancienne clé secrète pour l'utilisateur cible.
set -privilege advanced vserver object-store-server user show -user UIDRemplacez
UIDpar l'UID de l'utilisateur cible.Générez une clé d'accès et une clé secrète pour l'utilisateur cible dans le stockage d'objets. Les anciennes et nouvelles clés coexistent après cette étape, et les deux peuvent être utilisées pour l'accès.
vserver object-store-server user regenerate-keys -vserver root-admin -user UIDMettez à jour le secret Kubernetes avec la nouvelle clé d'accès et la nouvelle clé secrète. Il vous suffit de mettre à jour le secret dans le cluster d'infrastructure racine ou le cluster de gestion. Le secret est propagé aux autres clusters si nécessaire.
kubectl --kubeconfig KUBECONFIG patch secret -n SECRET_NAMESPACE SECRET_NAME --type='json' -p='[{"op": "replace", "path": "/data/access-key-id", "value": "'"$(echo -n "ACCESS_KEY" | base64)"'"}, {"op": "replace", "path": "/data/secret-access-key", "value": "'"$(echo -n "ACCESS_KEY" | base64)"'"}]'Remplacez les éléments suivants :
KUBECONFIG: chemin d'accès au fichier kubeconfig. Le serveur d'API doit être le serveur d'API du plan de contrôle pour l'utilisateurroot. S'il ne l'est pas, il doit s'agir du serveur d'API de gestion.SECRET_NAME: nom secret de l'utilisateur, qui peut être dérivé de la section Traduire l'UID. Si l'utilisateur dispose de plusieurs secrets Kubernetes (par exemple,root), remplacez par chaque nom de secret et exécutez la commande.SECRET_NAMESPACE: espace de noms secret pour l'utilisateur, qui peut être dérivé de la section Traduire l'UID.ACCESS_KEY: nouvelle clé d'accès générée à l'étape précédente.SECRET_KEY: nouvelle clé secrète générée à l'étape précédente.
La charge de travail qui consomme le secret doit être implémentée pour s'actualiser automatiquement. Si ce n'est pas le cas, vous devez redémarrer la charge de travail pour que la modification du secret soit prise en compte.
Par exemple, pour l'utilisateur
root, vous devez redémarrer les charges de travail suivantes dans le cluster d'infrastructure :kubectl --kubeconfig KUBECONFIG rollout restart deployment obj-bucket-cm-backend-controller -n obj-system
Validation
Suivez les instructions Créer un bucket et Importer et télécharger des objets d'Object Storage pour créer un bucket et accorder l'accès à l'aide du contrôle d'accès basé sur les rôles. La rotation des clés de stockage d'objets est terminée si le bucket est créé et que le sujet dispose des autorisations nécessaires pour y accéder.