Restringe acciones en los recursos de GKE mediante políticas de la organización personalizadas

En esta página, se muestra cómo restringir operaciones específicas en los recursos de Google Kubernetes Engine (GKE) de tu organización con restricciones personalizadas en el Google Cloud servicio de políticas de la organización. Puedes usar restricciones para ayudar a tu organización a cumplir con los requisitos de cumplimiento, seguridad y políticas, ya que garantizan que los recursos del clúster cumplan con requisitos específicos. En esta página, aprenderás a crear restricciones personalizadas y aplicarlas a los recursos de tu clúster.

Esta página está dirigida a los especialistas en seguridad que se aseguran de que su organización cumpla con los requisitos de cumplimiento, seguridad y políticas limitando o exigiendo configuraciones específicas en los recursos del clúster. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido de Google Cloud , consulta Roles y tareas comunes de los usuarios de GKE.

Antes de leer esta página, asegúrate de estar familiarizado con las políticas de la Organización.

Acerca de las políticas y restricciones de la organización

La Google Cloud política de la organización te brinda un control centralizado y programático sobre los recursos de tu organización. Como administrador de políticas de la organización, puedes definir una política de la organización, que es un conjunto de limitaciones llamadas restricciones que se aplican a los recursos de Google Cloud y a sus descendientes en la Google Cloud jerarquía de recursos. Puedes aplicar políticas de la organización a nivel de la organización, carpeta o proyecto.

La política de la organización proporciona restricciones predefinidas para varios servicios de Google Cloud . Sin embargo, si deseas un control más detallado y personalizable sobre los campos específicos que están restringidos en las políticas de tu organización, también puedes crear restricciones personalizadas y usarlas en una política de la organización personalizada.

Recursos admitidos en GKE

Para GKE, puedes crear restricciones personalizadas para los métodos CREATE o UPDATE en cualquier campo del recurso Cluster o NodePool de la API de Google Kubernetes Engine v1, excepto para campos solo de salida y los siguientes campos:

  • projects.locations.clusters.masterAuth.clientKey
  • projects.locations.clusters.masterAuth.password

Herencia de políticas

De forma predeterminada, las políticas se heredan según los subordinados de los recursos en los que se aplica la política. Por ejemplo, si aplicas una política en una carpeta,Google Cloud aplica la política en todos los proyectos de la carpeta. Para obtener más información sobre este comportamiento y cómo cambiarlo, consulta Reglas de evaluación de la jerarquía.

Precios

Las políticas y las restricciones de la organización se ofrecen sin cargo.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

  • Habilita la API de Google Kubernetes Engine.
  • Habilitar la API de Google Kubernetes Engine
  • Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta el comando gcloud components update para obtener la versión más reciente. Es posible que las versiones anteriores de gcloud CLI no admitan la ejecución de los comandos que se describen en este documento.

Crea una restricción personalizada

Para crear una nueva restricción personalizada, debes definir la restricción en un archivo YAML y aplicar la restricción personalizada en tu organización con Google Cloud CLI.

  1. Crea un archivo YAML para la restricción personalizada:

    name: organizations/ORGANIZATION_ID/customConstraints/custom.CONSTRAINT_NAME
    resourceTypes:
    - container.googleapis.com/RESOURCE_NAME
    methodTypes:
    - METHOD1
    - METHOD2
    condition: "resource.OBJECT_NAME.FIELD_NAME == VALUE"
    actionType: ACTION
    displayName: DISPLAY_NAME
    description: DESCRIPTION
    

    Reemplaza lo siguiente:

    • ORGANIZATION_ID: el ID de la organización, como 123456789.
    • CONSTRAINT_NAME: el nombre que deseas para tu nueva restricción personalizada. Una restricción personalizada debe comenzar con custom. y solo puede incluir letras mayúsculas, minúsculas o números, por ejemplo, custom.enableGkeAutopilot. La longitud máxima de este campo es de 70 caracteres, sin contar el prefijo (por ejemplo, organizations/123456789/customConstraints/custom.).
    • RESOURCE_NAME: el nombre (no el URI) del recurso REST de la API de GKE que contiene el objeto y el campo que deseas restringir. Por ejemplo, Cluster o NodePool.
    • METHOD1,METHOD2,...: una lista de métodos de RESTful para aplicar la restricción. Puede ser CREATE o CREATE y UPDATE.
    • condition: la condición para validar la solicitud según la escritura en Common Expression Language (CEL). La longitud máxima de este campo es 1000 caracteres. La expresión debe contener los siguientes campos, y admite operadores lógicos como && y ||:

      • OBJECT_NAME: el nombre del objeto de la API de GKE que deseas restringir, en formato pascalCase. Por ejemplo, privateClusterConfig.
      • FIELD_NAME: el nombre del campo de la API de GKE que deseas restringir, en formato pascalCase. Por ejemplo, enablePrivateNodes.
      • VALUE: el valor del campo. Para los campos booleanos, usa true o false. Para los campos de string, usa "STRING".
    • ACTION: la acción que se realiza si se cumple condition. Puede ser ALLOW o DENY.

    • DISPLAY_NAME: un nombre descriptivo para la restricción. La longitud máxima de este campo es 200 caracteres.

    • DESCRIPTION: una descripción fácil de usar de la restricción que se mostrará como un mensaje de error cuando se infringe la política. La longitud máxima de este campo es 2000 caracteres.

  2. Aplica la restricción personalizada:

    gcloud org-policies set-custom-constraint PATH_TO_FILE
    

    Reemplaza PATH_TO_FILE por la ruta de acceso del archivo de la definición de tu restricción personalizada.

  3. Verifica que exista la restricción personalizada:

    gcloud org-policies list-custom-constraints --organization=ORGANIZATION_ID
    

    El resultado es similar a este:

    CONSTRAINT                     LIST_POLICY    BOOLEAN_POLICY    ETAG
    custom.enableGkeAutopilot      -              SET               COCsm5QGENiXi2E=
    ...
    

Aplica la restricción personalizada

Para aplicar la nueva restricción personalizada, crea una política de la organización que haga referencia a la restricción y, luego, aplica la política de la organización.

  1. Crea un archivo YAML para la política de la organización:

    name: RESOURCE_HIERARCHY/policies/POLICY_NAME
    spec:
      rules:
      - enforce: true
    

    Reemplaza lo siguiente:

    • RESOURCE_HIERARCHY: la ubicación de la política nueva, que afecta el alcance de la aplicación. Usa la jerarquía de recursos deGoogle Cloud como guía. Por ejemplo, si deseas aplicar la política en un proyecto específico, usa projects/PROJECT_ID. Para aplicar la política en una organización específica, usa organizations/ORGANIZATION_ID.
    • POLICY_NAME: el nombre de la política nueva.
  2. Aplica la política:

    gcloud org-policies set-policy PATH_TO_POLICY
    

    Reemplaza PATH_TO_POLICY por la ruta de acceso al archivo de definición de la política.

  3. Verifica que la política exista:

    gcloud org-policies list \
        --RESOURCE_FLAG=RESOURCE_ID
    

    Reemplaza lo siguiente:

    • RESOURCE_FLAG: El recurso Google Cloud en el que aplicaste la política. Por ejemplo: project o folder.
    • RESOURCE_ID: el ID del recurso en el que aplicaste la política. Por ejemplo, el ID de tu carpeta Google Cloud .

    Para obtener una lista de argumentos, consulta gcloud org-policies list.

    El resultado es similar a este:

    CONSTRAINT                                    LIST_POLICY    BOOLEAN_POLICY    ETAG
    iam.disableWorkloadIdentityClusterCreation    -              SET               CO3UkJAGEOj1qsQB
    custom.enableGkeAutopilot                     -              SET               COCsm5QGENiXi2E=
    custom.enableBinAuth                          -              SET               CJfKiZUGEJju7LUD
    

Ejemplo: crea una restricción personalizada y aplica una política

En el siguiente ejemplo, se crea una restricción y una política personalizadas que requieren que todos los clústeres nuevos en un proyecto específico sean clústeres de Autopilot.

Antes de comenzar, debes saber lo siguiente:

  • El ID de tu organización
  • Un ID del proyecto

Crea la restricción

  1. Guarda el siguiente archivo como constraint-enable-autopilot.yaml:

    name: organizations/ORGANIZATION_ID/customConstraints/custom.enableGkeAutopilot
    resourceTypes:
    - container.googleapis.com/Cluster
    methodTypes:
    - CREATE
    condition: "resource.autopilot.enabled == false"
    actionType: DENY
    displayName: Enable GKE Autopilot
    description: All new clusters must be Autopilot clusters.
    

    Esto define una restricción en la que, para cada clúster nuevo, la operación se rechaza si el modo de clúster no es Autopilot.

  2. Aplica la restricción:

    gcloud org-policies set-custom-constraint ~/constraint-enable-autopilot.yaml
    
  3. Verifica que la restricción exista:

    gcloud org-policies list-custom-constraints --organization=ORGANIZATION_ID
    

    El resultado es similar a este:

    CUSTOM_CONSTRAINT                       ACTION_TYPE  METHOD_TYPES   RESOURCE_TYPES                     DISPLAY_NAME
    custom.enableGkeAutopilot               DENY         CREATE         container.googleapis.com/Cluster   Enable GKE Autopilot
    ...
    

Crea la política

  1. Guarda el siguiente archivo como policy-enable-autopilot.yaml:

    name: projects/PROJECT_ID/policies/custom.enableGkeAutopilot
    spec:
      rules:
      - enforce: true
    

    Reemplaza PROJECT_ID con el ID del proyecto.

  2. Aplica la política:

    gcloud org-policies set-policy ~/policy-enable-autopilot.yaml
    
  3. Verifica que la política exista:

    gcloud org-policies list --project=PROJECT_ID
    

    El resultado es similar a este:

    CONSTRAINT                  LIST_POLICY    BOOLEAN_POLICY    ETAG
    custom.enableGkeAutopilot   -              SET               COCsm5QGENiXi2E=
    

Después de aplicar la política, espera unos dos minutos para que Google Cloud comience a aplicarla.

Prueba la política

Intenta crear un clúster de GKE Standard en el proyecto:

gcloud container clusters create org-policy-test \
    --project=PROJECT_ID \
    --location=CONTROL_PLANE_LOCATION \
    --num-nodes=1

Reemplaza lo siguiente:

  • PROJECT_ID: Es el ID del proyecto de la política.
  • CONTROL_PLANE_LOCATION: Es la ubicación de Compute Engine del plano de control de tu clúster. Proporciona una región para los clústeres regionales o una zona para los clústeres zonales.

Esta es la salida:

Operation denied by custom org policies: ["customConstraints/custom.enableGkeAutopilot": "All new clusters must be Autopilot clusters."]

Explora restricciones personalizadas de muestra para casos de uso comunes

En los siguientes ejemplos, se proporciona la sintaxis de algunas restricciones personalizadas que pueden resultarte útiles, como la aplicación de la federación de identidades para cargas de trabajo para GKE en clústeres nuevos. Para usar estas muestras, modifica los ejemplos según sea necesario para que se adapten a tu caso de uso específico. Luego, sigue las instrucciones de esta página para aplicarlos a tu organización.

Descripción Sintaxis de la restricción
Solo permite la creación de clústeres cuando la Autorización Binaria está habilitada
    name: organizations/ORGANIZATION_ID/customConstraints/custom.gkeBinaryAuthorization
    resourceTypes:
    - container.googleapis.com/Cluster
    methodTypes:
    - CREATE
    condition: "resource.binaryAuthorization.enabled == true || resource.binaryAuthorization.evaluationMode=='PROJECT_SINGLETON_POLICY_ENFORCE'"
    action: ALLOW
    displayName: Enable GKE Binary Authorization
    description: All new clusters must enable Binary Authorization.
No inhabilites la actualización automática de nodos para grupos de nodos nuevos
    name: organizations/ORGANIZATION_ID/customConstraints/custom.enableAutoUpgrade
    resourceTypes:
    - container.googleapis.com/NodePool
    methodTypes:
    - CREATE
    condition: "resource.management.autoUpgrade == true"
    actionType: ALLOW
    displayName: Enable node auto-upgrade
    description: All node pools must have node auto-upgrade enabled.
Habilita la federación de identidades para cargas de trabajo para GKE para clústeres nuevos
    name: organizations/ORGANIZATION_ID/customConstraints/custom.enableWorkloadIdentity
    resourceTypes:
    - container.googleapis.com/Cluster
    methodTypes:
    - CREATE
    condition: "has(resource.workloadIdentityConfig.workloadPool) || resource.workloadIdentityConfig.workloadPool.size() > 0"
    actionType: ALLOW
    displayName: Enable Workload Identity on new clusters
    description: All new clusters must use Workload Identity.
No inhabilites Cloud Logging en clústeres existentes
    name: organizations/ORGANIZATION_ID/customConstraints/custom.enableLogging
    resourceTypes:
    - container.googleapis.com/Cluster
    methodTypes:
    - UPDATE
    condition: "resource.loggingService == 'none'"
    actionType: DENY
    displayName: Do not disable Cloud Logging
    description: You cannot disable Cloud Logging on existing GKE cluster.
Solo permite la creación o actualización de grupos de nodos Standard cuando los extremos de metadatos heredados están inhabilitados
    name: organizations/ORGANIZATION_ID/customConstraints/custom.nodeConfigMetadata
    resourceTypes:
    - container.googleapis.com/NodePool
    methodTypes:
    - CREATE
    - UPDATE
    condition: "'disable-legacy-endpoints' in resource.config.metadata && resource.config.metadata['disable-legacy-endpoints'] == 'true'"
    actionType: ALLOW
    displayName: Disable legacy metadata endpoints
    description: You can only create or update node pools if you disable legacy
    metadata endpoints.

En este ejemplo de restricción, se muestra cómo configurar una restricción personalizada en un valor de mapa. El campo condition usa el operador de índice en la clave de mapa disable-legacy-endpoints. Si, en cambio, usas la sintaxis de selección de campo normal, como en los ejemplos anteriores, verás un error INVALID_CUSTOM_CONSTRAINT_CONDITION.

¿Qué sigue?