Aumenta los límites de la política de retención

En Google Distributed Cloud (GDC) aislado, hay una restricción que impide que los usuarios superen una política de retención máxima establecida GDCHRestrictAttributeRange. El Controlador de políticas de Anthos Config Management aplica esta restricción en los recursos personalizados (CR) de Bucket en los clústeres de administrador de la organización. Esto significa que, de forma predeterminada, solo las cuentas de servicio del sistema, los usuarios del sistema y los usuarios dentro del grupo system:masters pueden quitar los finalizadores. El procedimiento descrito abarca cómo aumentar los límites de la política de retención en los CR de Bucket.

Requisitos previos

Genera el archivo KUBECONFIG para el clúster

Los comandos de Kubectl requieren un archivo KUBECONFIG válido para funcionar. En este proceso, se proporcionan instrucciones paso a paso para generar el archivo KUBECONFIG para los clústeres de administrador raíz, administrador de la organización, sistema de la organización y usuario.

Requisitos previos

Antes de continuar, asegúrate de tener lo siguiente:

  • Se instaló gdcloud.

  • La CLI de kubectl está instalada.

  • Un certificado firmado por una autoridad certificadora (CA) instalado en la estación de trabajo

  • Es el nombre de la organización.

  • Es la URL raíz (GDC). El administrador de TI de la OC debe proporcionarte la URL raíz.

Configura las variables de entorno obligatorias

Sigue las instrucciones de esta sección para generar el archivo KUBECONFIG para org-admin, system o cualquier clúster de usuario.

  1. Ejecuta el siguiente comando para definir la variable de entorno ORG para su uso posterior en la terminal actual. ORG es el nombre de tu organización.

    export ORG=

  2. Ejecuta el siguiente comando para definir la variable de entorno CONSOLE_URL para su uso posterior en la terminal actual:

    export CONSOLE_URL=https://console.${ORG:?}.$GDC_URL/
gdcloud config set core/organization_console_url ${CONSOLE_URL:?}

    Reemplaza GDC_URL por la URL base de tu proyecto de GDC.

Accede al clúster

  1. Ejecuta el siguiente comando para acceder:

    gdcloud auth login --no-browser

  2. Copia el comando de gcloud que se imprime y ejecútalo en una máquina con acceso al navegador.

  3. Copia la URL que se imprimió y pégala en la barra de direcciones de un navegador web.

  4. Sigue las instrucciones de la página web para completar el proceso de acceso.

  5. Cuando se completa el acceso correctamente, el navegador muestra el mensaje Authentication successful. Cierra esta ventana.

  6. Sigue las instrucciones que aparecen en la terminal. Si el acceso se realiza correctamente, la terminal mostrará el mensaje You are now logged in.

Genera el archivo KUBECONFIG

  1. Ejecuta el siguiente comando para definir la variable de entorno CLUSTER para su uso posterior en la terminal actual. CLUSTER es el nombre del clúster deseado.

    export CLUSTER=

    Consulta la siguiente tabla para derivar el nombre del clúster reemplazando ORGANIZATION-NAME y CLUSTER-NAME por los valores adecuados:

    Clúster Nombre del clúster
    Administrador raíz root-admin
    Administrador de la organización ORGANIZATION-NAME-admin
    Sistema de organización ORGANIZATION-NAME-system
    usuario CLUSTER-NAME

    Verás que cada uno de los nombres representa lo siguiente:

    • El nombre del clúster de administrador raíz es root-admin.
    • Los nombres del clúster del sistema de la organización y del clúster de administrador de la organización para una organización llamada amira son amira-admin y amira-system, respectivamente.
    • Los nombres de los clústeres de usuarios son sus nombres de clúster.

  2. Ejecuta el siguiente comando para generar el archivo KUBECONFIG y validar las credenciales: sh export KUBECONFIG=${HOME}/${CLUSTER:?}-kubeconfig.yaml rm ${KUBECONFIG:?} gdcloud clusters get-credentials ${CLUSTER:?} [[ $(kubectl config current-context) == *${CLUSTER:?}* ]] && echo "Success. Your kubeconfig is at $KUBECONFIG" || echo "Failure" El comando debería devolver el siguiente resultado:

    Success. Your kubeconfig is at /usr/local/google/home/iris/kubeconfig-amira-admin.yaml

Obtén el rol de administrador de políticas en el clúster

Este proceso te ayuda a obtener acceso elevado temporal a un clúster.

Requisitos previos

Antes de continuar, asegúrate de tener lo siguiente:

  • Otro IO que actuará como aprobador de solicitudes de GitLab. El IO debe tener permisos para aprobar una solicitud de GitLab.
  • Es el nombre del clúster al que necesitas acceder. Por ejemplo: root-admin, org-1-admin.
  • Es el tipo de rol que deseas asumir. Por ejemplo, Role ClusterRole, ProjectRole o OrganizationRole.
  • Es el rol que deseas asumir.
  • Es el espacio de nombres del acceso requerido. No se necesita para ClusterRole y OrganizationRole.
  • Acceso a una estación de trabajo de TI de OC
  • Credenciales para GitLab

Ejecuta elevated-access-script

  1. Desde el directorio private-cloud/operations/tools/ de tu estación de trabajo, ejecuta la secuencia de comandos elevated-access-script.sh.

  2. Responde la pregunta "Please enter the GDCH_URL of the cluster…" con $GDCH_URL.

  3. Responde la pregunta "Enter Gitlab username:" con el nombre de usuario que usas para acceder a Gitlab.

  4. En la pregunta "Enter Gitlab personal access token:", ingresa el token de acceso personal de tu cuenta. Para crear un token de acceso personal, sigue estas instrucciones:

    1. Ve a https://gitlab.$GDCH_URL/gdch/iac. Accede a tu cuenta de IO Gitlab.

    2. Selecciona tu avatar.

    3. Selecciona Editar perfil.

    4. En el menú de navegación, selecciona Tokens de acceso.

    5. Ingresa un nombre y una fecha de vencimiento para el token.

    6. Selecciona los permisos deseados.

    7. Selecciona Crear un token de acceso personal.

  5. Ahora, la secuencia de comandos clonará el repositorio iac en tu directorio local.

  6. Responde la pregunta "Ingresa tu prefijo de IdP". El IdP Prefix es un prefijo específico de cada proveedor de identidad que se antepone a cada nombre de usuario dentro de un clúster de GDC. Para encontrar este prefijo, puedes hacer lo siguiente:

    • consultar con el Watch Commander
    • Recuperar instrucciones de la configuración de GDC, específicamente la sección "Administración de identidades y accesos" en la Guía del usuario de operadores

    La forma habitual de este prefijo será un conjunto de palabras seguido de un delimitador, es decir, gdch-infra-operator-.

  7. Responde la pregunta "Ingresa tu nombre de usuario" con el nombre de usuario que usas para acceder a tu proveedor de identidad.

  8. Responde la pregunta "Enter the cluster you need the role for" con el nombre del clúster para el que necesitarás el rol.

  9. La secuencia de comandos te pedirá que elijas un tipo de rol de Kubernetes. Escribe el tipo de rol que solicitas.

  10. Responde la pregunta "Ingresa el rol que necesitas asumir" con el nombre del rol.

  11. Ingresa la duración del acceso del rol. La duración de acceso recomendada es de 3 horas.

  12. La secuencia de comandos generará tres archivos YAML.

    1. ./iac/infrastructure/zonal/zones/ZONE_NAME/${CLUSTER}/kustomization.yaml
    2. ./iac/infrastructure/zonal/zones/ZONE_NAME/${CLUSTER}/${USER}-bindings/kustomization.yaml
    3. ./iac/infrastructure/zonal/zones/ZONE_NAME/${CLUSTER}/${USER}-bindings/${ROLE}-binding.yaml

    Para confirmar que cada archivo es correcto, presiona Y o presiona N para editar el archivo en vim.

  13. Después de confirmar todos los archivos, la secuencia de comandos los enviará a una rama elevated_access en GitLab y creará una solicitud de combinación.

Revisa y aprueba la solicitud de acceso elevado

En la siguiente lista, se especifican las acciones que se realizan para una solicitud de acceso elevado de revisión y aprobación:

  1. Otro IO revisa la solicitud de GitLab, incluidos los archivos de configuración de políticas, para aprobar la solicitud de manera adecuada.
  2. Una vez que la IO aprueba la solicitud, el sistema otorga acceso por el período solicitado.
  3. El sistema revoca el acceso después del tiempo de vencimiento establecido.

Restricción de parche

Después de obtener el acceso requerido, ejecuta el siguiente comando para establecer el nuevo máximo de la política de retención del bucket. En este ejemplo, se muestra un nuevo máximo de 120 días, pero asegúrate de actualizar el comando al valor que solicitó tu administrador de la plataforma (PA):

kubectl patch GDCHRestrictAttributeRange restrict-bucket-retention-policy -p '{"spec":{"parameters":{"attributeMaxValue":120}}}' --type=merge

El resultado debe verse de la siguiente manera:

gdchrestrictattributerange.constraints.gatekeeper.sh/restrict-bucket-retention-policy patched