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

En Google Distributed Cloud (GDC) con air gap, hay una restricción que impide que los usuarios superen una política de retención máxima definida GDCHRestrictAttributeRange. El Policy Controller de Anthos Config Management aplica esta restricción a los recursos personalizados de los segmentos 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 del grupo system:masters pueden eliminar los finalizadores. El procedimiento descrito explica cómo aumentar los límites de la política de conservación en los CRs de segmentos.

Requisitos previos

Generar el archivo KUBECONFIG del 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 de 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 que tienes lo siguiente:

  • gdcloud está instalado.

  • La CLI de kubectl está instalada.

  • Un certificado firmado por una autoridad de certificación (AC) instalada en la estación de trabajo.

  • Nombre de la organización.

  • La URL raíz de GDC. El administrador de TI de la OC debe proporcionarte la URL raíz.

Definir las variables de entorno necesarias

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

  1. Ejecuta el siguiente comando para definir la variable de entorno ORG y usarla más adelante en el 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 y usarla más adelante en el terminal actual:

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

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

Iniciar sesión en el clúster

  1. Ejecuta el siguiente comando para iniciar sesión:

    gdcloud auth login --no-browser

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

  3. Copia la URL que se imprime 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 inicio de sesión.

  5. Cuando se haya completado el inicio de sesión, el navegador mostrará el mensaje Autenticación correcta. Cierra esta ventana.

  6. Sigue las instrucciones del terminal. Si el inicio de sesión se realiza correctamente, el terminal mostrará el mensaje Has iniciado sesión.

Generar el archivo KUBECONFIG

  1. Ejecuta el siguiente comando para definir la variable de entorno CLUSTER y usarla más adelante en el terminal actual. CLUSTER es el nombre del clúster que quieres.

    export CLUSTER=

    Consulta la siguiente tabla para obtener el nombre del clúster. Para ello, sustituye ORGANIZATION-NAME y CLUSTER-NAME por los valores correspondientes:

    Clúster Nombre del clúster
    administrador raíz administrador raíz
    Administrador de la organización ORGANIZATION-NAME-admin
    sistema de la 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 y del administrador de la organización amira son amira-admin y amira-system, respectivamente.
    • Los nombres de los clústeres de usuarios son los nombres de los clústeres.

  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

Obtener 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 que tienes lo siguiente:

  • Otra orden de inserción para actuar como aprobador de solicitudes de GitLab. El IO debe tener permisos para aprobar una solicitud de GitLab.
  • El nombre del clúster al que necesitas acceder. Por ejemplo: root-admin, org-1-admin.
  • El tipo de rol que quieres asumir. Por ejemplo: Role ClusterRole, ProjectRole o OrganizationRole.
  • El rol que quieres asumir.
  • Espacio de nombres del acceso necesario. No es necesario para ClusterRole y OrganizationRole.
  • Acceso a una estación de trabajo de TI de OC.
  • Credenciales de GitLab.

Ejecutar elevated-access-script

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

  2. Responde a la pregunta "Please enter the GDCH_URL of the cluster..." (Introduce la URL de GDCH del clúster...) con $GDCH_URL.

  3. Responde a la pregunta "Enter Gitlab username:" (Introduce el nombre de usuario de GitLab) con el nombre de usuario que usas para iniciar sesión en GitLab.

  4. En la pregunta "Enter Gitlab personal access token:" (Introduce el token de acceso personal de GitLab), introduce 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. Inicia sesión en 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. Introduce un nombre y una fecha de vencimiento para el token.

    6. Selecciona los ámbitos que quieras.

    7. Selecciona Crear token de acceso personal.

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

  6. Responde a la pregunta "Enter your IdP prefix" (Introduce el prefijo de tu proveedor de identidades). El IdP Prefix es un prefijo específico de cada proveedor de identidades que se añade antes de cada nombre de usuario de un clúster de GDC. Puedes encontrar este prefijo de dos formas:

    • consultar a tu Watch Commander
    • recuperar instrucciones de la configuración de GDC, concretamente de la sección "Gestión de identidades y accesos" de 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 a la pregunta "Introduce tu nombre de usuario" con el nombre de usuario que usas para iniciar sesión en tu proveedor de identidades.

  8. Responde a la pregunta "Enter the cluster you need the role for" (Introduce el clúster para el que necesitas el rol) con el nombre del clúster para el que necesitas 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 a la pregunta "Introduce el rol que quieres asumir" con el nombre del rol.

  11. Introduce 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

    Confirma que cada archivo es correcto pulsando Y o pulsa N para editar el archivo en vim.

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

Revisar y aprobar una solicitud de acceso elevado

En la siguiente lista se especifican las acciones que se llevan a cabo en 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 la política, para aprobarla correctamente.
  2. Una vez que el IO aprueba la solicitud, el sistema concede acceso durante el periodo solicitado.
  3. El sistema revoca el acceso una vez transcurrido el tiempo de vencimiento establecido.

Restricción de parche

Después de obtener el acceso necesario, ejecuta el siguiente comando para definir el nuevo máximo de la política de conservació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 te indique el administrador de la plataforma:

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

La salida debería tener este aspecto:

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