Rotar las credenciales de almacenamiento de objetos

El almacenamiento de objetos del dispositivo air-gapped de Google Distributed Cloud (GDC) se proporciona mediante OTS (ONTAP Select). OTS tiene su propio sistema de gestión de usuarios de almacenamiento de objetos. Las credenciales de cada usuario de almacenamiento de objetos OTS se almacenan como un secreto en los clústeres.

En este documento se describen los pasos para rotar las credenciales de usuario de almacenamiento de objetos de OTS. Rota las credenciales de usuario de almacenamiento de objetos en las siguientes situaciones:

  • Rotación de claves programada periódicamente para rotar todas las claves de usuario.
  • mitigar la exposición clave. Debes cambiar la clave de usuario expuesta lo antes posible.

Antes de empezar

Este agente debe seguir estos pasos:

  1. Comprueba que cumples los requisitos previos para portátiles.
  2. Asegúrate de que puedes iniciar sesión en el clúster de OTS y ejecutar comandos de la CLI vserver object-store-server.
  3. Comprueba que puedes iniciar sesión como administrador en el clúster de infraestructura y en el clúster de gestión mediante kubectl.

Translate UID

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 backend. Rotar las claves de usuario implica actualizar todos los secretos.

Para obtener una lista de usuarios de almacenamiento de objetos, inicia sesión en uno de los tres nodos con el siguiente comando:

vserver object-store-server user show

La salida es una lista de UIDs y debería ser similar a la siguiente:

[
    "root",
    "k8ssa_gpc-system_inventory-export-images",
    "k8ssa_gpc-system_inventory-export-hardware",
    "k8su_test-user@example.com"
]

Hay tres tipos de usuarios:

Usuarios del almacenamiento de objetos
UID Tipo de usuario Nombre del secreto Espacio de nombres del 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_&ltnamespace>_&ltsa> Cuenta de servicio de Kubernetes object-storage-key-std-sa-&ltencoded-sa> &ltnamespace>
k8su_&ltnombre_de_usuario> Usuario de Kubernetes object-storage-key-std-user-&ltencoded-username> object-storage-access-keys

El usuario root tiene tres secretos idénticos, que reflejan la estructura del centro de datos, que abarca varias clases de almacenamiento y categorías de inquilinos. Por el contrario, Appliance solo tiene un nivel de almacenamiento de objetos. Los tres secretos asociados al usuario raíz deben rotarse simultáneamente.

La identificación de usuario (UID), excluido el usuario root, debe cumplir 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'

Sustituye UID_SUFFIX por <sa> en el UID y obtendrás <encoded-sa>.

Sustituye UID_SUFFIX por <username> en el UID y obtendrás <encoded-username>.

Rotar la clave de usuario

  1. Inicia sesión en el clúster de OTS.

  2. Obtiene una lista de UIDs de usuarios de almacenamiento de objetos.

    vserver object-store-server user show

    El resultado es una lista de UIDs. Puede consultar ejemplos en UID de traducción. Repite los pasos siguientes para cada UID de la lista.

  3. Obtén la clave de acceso y la clave secreta antiguas del usuario de destino.

    set -privilege advanced
vserver object-store-server user show -user UID

    Sustituye UID por el UID del usuario objetivo.

  4. Genera una nueva clave de acceso y una clave secreta para el usuario de destino en el almacenamiento de objetos. Las claves antiguas y las nuevas coexistirán después de este paso, y ambas se podrán usar para acceder.

    vserver object-store-server user regenerate-keys -vserver root-admin -user UID

  5. Actualiza el secreto de Kubernetes con la nueva clave de acceso y la clave secreta. Solo tienes que actualizar el secreto en el clúster de infraestructura raíz o en el clúster de gestió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)"'"}]'

    Haz los cambios siguientes:

    • KUBECONFIG: la ruta a kubeconfig. El servidor de la API debe ser el servidor de la API del plano de control del usuario root. De lo contrario, debe ser el servidor de la API de gestión.
    • SECRET_NAME: el nombre secreto del usuario, que se puede obtener en la sección Traducir UID. Si el usuario tiene varios secretos de Kubernetes (es decir, root), sustituye por cada nombre secreto y ejecuta el comando.
    • SECRET_NAMESPACE: el espacio de nombres secreto del usuario, que se puede obtener de la sección UID de traducción.
    • ACCESS_KEY: la nueva clave de acceso generada en el paso anterior.
    • SECRET_KEY: la nueva clave secreta generada en el paso anterior.

  6. La carga de trabajo que consume el secreto debe implementarse para que se actualice automáticamente. Si no es así, 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 para crear un segmento y subir y descargar objetos de Object Storage para crear un segmento y conceder acceso mediante el control de acceso basado en roles. La rotación de claves de almacenamiento de objetos se completa si el segmento se crea correctamente y el asunto tiene los permisos necesarios para acceder a él.