Restringir acciones en recursos de GKE mediante políticas de organización personalizadas

En esta página se explica cómo restringir operaciones específicas en recursos de Google Kubernetes Engine (GKE) de tu organización mediante restricciones personalizadas en el Trusted Cloud by S3NS servicio Organization Policy. Puedes usar restricciones para ayudar a tu organización a cumplir los requisitos de cumplimiento, seguridad y políticas. Para ello, asegúrate de que los recursos del clúster cumplan requisitos específicos. En esta página se explica cómo crear restricciones personalizadas y aplicarlas a los recursos de tu clúster.

Esta página está dirigida a especialistas en seguridad que se aseguran de que su organización cumpla 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 habituales y las tareas de ejemplo a las que hacemos referencia en el contenido, consulta Roles y tareas habituales de los usuarios de GKE. Trusted Cloud by S3NS

Antes de leer esta página, asegúrate de que conoces las políticas de la organización.

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

La Trusted Cloud política de organización te permite controlar los recursos de tu organización de forma centralizada y programática. Como administrador de políticas de la organización, puedes definir una política de la organización, que es un conjunto de restricciones llamadas restricciones que se aplican a los recursos y a los elementos descendientes de esos recursos en la Trusted Cloud by S3NS jerarquía de recursos. Trusted Cloud Puedes aplicar políticas de organización a nivel de organización, carpeta o proyecto.

La política de organización proporciona restricciones predefinidas para varios servicios de Trusted Cloud . Sin embargo, si quieres tener un control más granular 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 organización personalizada.

Recursos admitidos en GKE

En 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 en los campos de solo salida y en 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 de los descendientes de los recursos en los que se aplican. Por ejemplo, si aplicas una política a una carpeta, se aplicará a todos los proyectos de la carpeta.Trusted Cloud Para obtener más información sobre este comportamiento y cómo cambiarlo, consulta las reglas de evaluación de la jerarquía.

Precios

Las políticas y las restricciones de organización se ofrecen sin coste económico.

Antes de empezar

Antes de empezar, asegúrate de que has realizado las siguientes tareas:

  • Habilita la API de Google Kubernetes Engine.
    • Habilitar la API de Google Kubernetes Engine
  • Si quieres usar Google Cloud CLI para esta tarea, instálala y, a continuación, inicialízala. Si ya has instalado la gcloud CLI, obtén la versión más reciente ejecutando gcloud components update.

Crear una restricción personalizada

Para crear una restricción personalizada, defínela en un archivo YAML y aplíquela en su organización con la CLI de Google Cloud.

  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

    Haz los cambios siguientes:

    • ORGANIZATION_ID: el ID de tu organización, como 123456789.
    • CONSTRAINT_NAME: el nombre que quieras asignar a la nueva restricción personalizada. Una restricción personalizada debe empezar por custom. y solo puede incluir letras mayúsculas, letras 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 quieres restringir. Por ejemplo, Cluster o NodePool.
    • METHOD1,METHOD2,...: lista de métodos RESTful para los que se debe aplicar la restricción. Puede ser CREATE o CREATE y UPDATE.

    • condition: la condición para validar la solicitud, escrita en lenguaje de expresión común (CEL). Este campo tiene una longitud máxima de 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 quieres restringir, en formato pascalCase. Por ejemplo, privateClusterConfig.
      • FIELD_NAME: el nombre del campo de la API de GKE que quieras restringir, en formato pascalCase. Por ejemplo, enablePrivateNodes.
      • VALUE: el valor del campo. En los campos booleanos, usa true o false. En el caso de los campos de cadena, usa "STRING".

    • ACTION: la acción que se debe llevar a cabo si se cumple la condición condition. Puede ser ALLOW o DENY.

    • DISPLAY_NAME: nombre descriptivo de la restricción. Este campo tiene una longitud máxima de 200 caracteres.

    • DESCRIPTION: descripción de la restricción que se mostrará como mensaje de error cuando se infrinja la política. Este campo tiene una longitud máxima de 2000 caracteres.

  2. Aplica la restricción personalizada:

    gcloud org-policies set-custom-constraint PATH_TO_FILE

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

  3. Verifica que la restricción personalizada exista:

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

    El resultado debería ser similar al siguiente:

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

Aplicar la restricción personalizada

Para aplicar la nueva restricción personalizada, crea una política de organización que haga referencia a la restricción y, a continuación, aplica la política de 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

    Haz los cambios siguientes:

    • RESOURCE_HIERARCHY: la ubicación de la nueva política, que afecta al ámbito de la medida. Usa la jerarquía de recursosTrusted Cloud como guía. Por ejemplo, si quieres 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 nueva política.

  2. Aplica la política:

    gcloud org-policies set-policy PATH_TO_POLICY

    Sustituye PATH_TO_POLICY por la ruta al archivo de definición de tu política.

  3. Comprueba que la política exista:

    gcloud org-policies list \
    --RESOURCE_FLAG=RESOURCE_ID

    Haz los cambios siguientes:

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

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

    El resultado debería ser similar al siguiente:

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

Ejemplo: Crear una restricción personalizada y aplicar 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 de un proyecto específico sean clústeres Autopilot.

Antes de empezar, debes saber lo siguiente:

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

Crear 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.

    Define una restricción por la que, en cada clúster nuevo, si el modo de clúster no es Autopilot, se deniega la operación.

  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 debería ser similar al siguiente:

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

Crear la política

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

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

    Sustituye PROJECT_ID por el ID del proyecto.

  2. Aplica la política:

    gcloud org-policies set-policy ~/policy-enable-autopilot.yaml

  3. Comprueba que la política exista:

    gcloud org-policies list --project=PROJECT_ID

    El resultado debería ser similar al siguiente:

    CONSTRAINT                  LIST_POLICY    BOOLEAN_POLICY    ETAG
custom.enableGkeAutopilot   -              SET               COCsm5QGENiXi2E=

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

Probar la política

Intenta crear un clúster estándar de GKE en el proyecto:

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

Haz los cambios siguientes:

  • PROJECT_ID: el ID del proyecto de la política.
  • CONTROL_PLANE_LOCATION: 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.

El resultado es el siguiente:

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

Consultar ejemplos de restricciones personalizadas para casos de uso habituales

En los siguientes ejemplos se muestra la sintaxis de algunas restricciones personalizadas que pueden resultarte útiles, como la de aplicar Workload Identity Federation para GKE en clústeres nuevos. Para usar estas muestras, modifique los ejemplos según sea necesario para adaptarlos a su caso práctico específico. A continuación, aplícalos a tu organización siguiendo las instrucciones de esta página.

Descripción Sintaxis de las restricciones
Solo permite crear 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 inhabilite la actualización automática de nodos en los 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.
Habilitar Workload Identity Federation para GKE en 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 inhabilitar Cloud Logging en clústeres disponibles 
    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 permitir la creación o actualización de grupos de nodos estándar cuando los endpoints de metadatos antiguos 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 definir 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 usas la sintaxis de selección de campos normal, como en los ejemplos anteriores, verás un error INVALID_CUSTOM_CONSTRAINT_CONDITION.

Siguientes pasos