El almacenamiento de objetos del dispositivo aislado de Google Distributed Cloud (GDC) lo proporciona OTS (ONTAP Select). OTS tiene su propio sistema de administración de usuarios de almacenamiento de objetos. Cada credencial de usuario de almacenamiento de objetos de OTS
se almacena como un secreto en los clústeres.
En este documento, se describen los pasos para rotar las credenciales de usuario del almacenamiento de objetos de OTS
. Rota las credenciales de usuario del almacenamiento de objetos en las siguientes situaciones:
- Rotación de claves programada con regularidad para rotar todas las claves de los usuarios
- mitigar la exposición de la llave. Debes rotar la clave del usuario expuesta lo antes posible.
Antes de comenzar
Completa los siguientes pasos:
- Verifica que cumplas con los requisitos de la laptop.
- Asegúrate de poder acceder al clúster de OTS y ejecutar comandos de la CLI de
vserver object-store-server
. - Asegúrate de poder acceder como administrador al clúster de infraestructura y al clúster de administración con
kubectl
.
UID de traducción
Cada usuario de almacenamiento de objetos tiene una clave de acceso y una clave secreta que se almacenan como un secreto de Kubernetes y que las cargas de trabajo de Kubernetes usan para acceder al almacenamiento de objetos de backend. La rotación de las claves del usuario incluye la actualización de todos los secretos.
Para obtener una lista de los usuarios del almacenamiento de objetos, accede a uno de los tres nodos con el siguiente comando:
vserver object-store-server user show
El resultado es una lista de UIDs y debería ser similar a lo siguiente:
[
"root",
"k8ssa_gpc-system_inventory-export-images",
"k8ssa_gpc-system_inventory-export-hardware",
"k8su_test-user@example.com"
]
Existen tres tipos de usuarios:
UID | Tipo de usuario | Nombre del secreto | Espacio de nombres secreto |
---|---|---|---|
raíz | Administrador de sistemas | 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> | Cuenta de servicio de Kubernetes | object-storage-key-std-sa-<encoded-sa> | <namespace> |
k8su_<username> | Usuario de Kubernetes | object-storage-key-std-user-<encoded-username> | object-storage-access-keys |
El usuario root
tiene tres secretos idénticos, lo que refleja la estructura del Centro de datos, que abarca varias clases de almacenamiento y categorías de inquilinos. En cambio, Appliance solo tiene un nivel de almacenamiento de objetos. Los tres secretos asociados con el usuario raíz deben rotarse de forma simultánea.
La identificación del usuario (UID), sin incluir al usuario root
, debe cumplir con el formato k8ssa_<namespace>_<sa>
o k8su_<username>
. Obtén <encoded-sa>
o <encoded-username>
:
echo -n 'UID_SUFFIX' | shasum -a 256 | cut -d " " -f 1 | xxd -r -p | base32 | awk '{print tolower($0)}' | sed 's/=*$//g'
Reemplaza UID_SUFFIX
por <sa>
en el UID y obtendrás <encoded-sa>
.
Reemplaza UID_SUFFIX
por <username>
en el UID y obtendrás <encoded-username>
.
Rotar la clave del usuario
Accede al clúster de OTS.
Obtén una lista de los UIDs de los usuarios del almacenamiento de objetos.
vserver object-store-server user show
El resultado es una lista de UIDs. Puedes encontrar ejemplos en Translate UID. Repite los siguientes pasos para cada UID de la lista.
Obtén la clave de acceso y la clave secreta anteriores para el usuario objetivo.
set -privilege advanced vserver object-store-server user show -user UID
Reemplaza
UID
por el UID del usuario objetivo.Genera una clave de acceso y una clave secreta nuevas para el usuario objetivo en el almacenamiento de objetos. Las claves antiguas y nuevas coexisten después de este paso, y ambas se pueden usar para el acceso.
vserver object-store-server user regenerate-keys -vserver root-admin -user UID
Actualiza el secreto de Kubernetes con la nueva clave de acceso y la clave secreta. Solo necesitas actualizar el secreto en el clúster raíz de infraestructura o en el clúster de administración, y el secreto se propagará a otros clústeres si es necesario.
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)"'"}]'
Reemplaza lo siguiente:
KUBECONFIG
: Es la ruta de acceso a kubeconfig. El servidor de la API debe ser el servidor de la API del plano de control para el usuario deroot
; de lo contrario, debe ser el servidor de la API de administración.SECRET_NAME
: Es el nombre secreto del usuario, que se puede derivar de la sección UID de Translate. Si el usuario tiene varios secretos de Kubernetes (es decir, usuarioroot
), reemplaza con cada nombre de secreto y ejecuta el comando.SECRET_NAMESPACE
: Es el espacio de nombres secreto del usuario, que se puede derivar de la sección UID de Translate.ACCESS_KEY
: Es la nueva clave de acceso que se generó en el paso anterior.SECRET_KEY
: Es la nueva clave secreta que se generó en el paso anterior.
La carga de trabajo que consume el secreto debe implementarse para que se actualice automáticamente. De lo contrario, debes reiniciar la carga de trabajo para que se refleje el cambio en el secreto.
Por ejemplo, para el usuario
root
, debes reiniciar las siguientes cargas de trabajo en el clúster de infraestructura:kubectl --kubeconfig KUBECONFIG rollout restart deployment obj-bucket-cm-backend-controller -n obj-system
Validación
Sigue los pasos de creación de buckets y carga y descarga de objetos de Object Storage para crear un bucket nuevo y otorgar acceso con RBAC. La rotación de claves de almacenamiento de objetos se completa si el bucket se crea correctamente y el sujeto tiene los permisos necesarios para acceder a él.