Crear recursos de Google Cloud que cumplan las políticas

En este tutorial se muestra cómo pueden usar los administradores de plataformas las políticas de Policy Controller para controlar cómo se crean los recursos Google Cloud con Config Connector.

Esta página está dirigida a administradores y operadores de TI que quieran asegurarse de que todos los recursos que se ejecutan en la plataforma en la nube cumplen los requisitos de cumplimiento de la organización proporcionando y manteniendo la automatización para auditar o aplicar, y que gestionan el ciclo de vida de la infraestructura tecnológica subyacente. 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 de usuario habituales de GKE.Google Cloud

En las instrucciones de este tutorial se presupone que tienes conocimientos básicos de Kubernetes o Google Kubernetes Engine (GKE). En el tutorial, definirás una política que restringe las ubicaciones permitidas para los segmentos de Cloud Storage.

Policy Controller comprueba, audita y aplica el cumplimiento de los recursos de tu clúster de Kubernetes con políticas relacionadas con la seguridad, las normativas o las reglas empresariales. Policy Controller se basa en el proyecto de código abierto OPA Gatekeeper.

Config Connector crea y gestiona el ciclo de vida de los Google Cloud recursos describiéndolos como recursos personalizados de Kubernetes. Para crear un Google Cloud recurso, crea un recurso de Kubernetes en un espacio de nombres que gestione Config Connector. En el siguiente ejemplo se muestra cómo describir un segmento de Cloud Storage con Config Connector:

apiVersion: storage.cnrm.cloud.google.com/v1beta1
kind: StorageBucket
metadata:
  name: my-bucket
spec:
  location: us-east1

Al gestionar tus Google Cloud recursos con Config Connector, puedes aplicar políticas de Policy Controller a esos recursos a medida que los creas en tu clúster de Google Kubernetes Engine. Estas políticas te permiten evitar o denunciar acciones que creen o modifiquen recursos de forma que infrinjan tus políticas. Por ejemplo, puedes aplicar una política que restrinja las ubicaciones de los segmentos de Cloud Storage.

Este enfoque, basado en el modelo de recursos de Kubernetes (KRM), te permite usar un conjunto coherente de herramientas y flujos de trabajo para gestionar tanto recursos de Kubernetes como de Google Cloud . En este tutorial se muestra cómo puedes completar las siguientes tareas:

  • Define políticas que rijan tus Google Cloud recursos.
  • Implementa controles que impidan que los desarrolladores y administradores creen recursos de Google Cloud que infrinjan tus políticas.
  • Implementa controles que auditen tus recursos de Google Cloud en función de tus políticas, aunque hayas creado esos recursos fuera de Config Connector.
  • Proporcionar comentarios rápidos a los desarrolladores y administradores a medida que crean y actualizan definiciones de recursos.
  • Valida las definiciones de recursos Google Cloud con tus políticas antes de intentar aplicar las definiciones a un clúster de Kubernetes.

Crear un clúster de GKE

  1. En Cloud Shell, crea un clúster de GKE con el complemento Config Connector y Workload Identity Federation para GKE:

    gcloud container clusters create CLUSTER_NAME \
  --addons ConfigConnector \
  --enable-ip-alias \
  --num-nodes 4 \
  --release-channel regular \
  --scopes cloud-platform \
  --workload-pool $GOOGLE_CLOUD_PROJECT.svc.id.goog \
  --zone ZONE

    Haz los cambios siguientes:

    • CLUSTER_NAME: el nombre del clúster que quieras usar en este proyecto (por ejemplo, cnrm-gatekeeper-tutorial).
    • ZONE: una zona de Compute Engine cercana a tu ubicación, por ejemplo, asia-southeast1-b.

    El complemento Config Connector instala definiciones de recursos personalizadas (CRDs) para los Google Cloud recursos de tu clúster de GKE.

  2. Opcional: Si usas un clúster privado en tu entorno, añade una regla de cortafuegos que permita que el plano de control del clúster de GKE se conecte al webhook de Policy Controller:

    gcloud compute firewall-rules create allow-cluster-control-plane-tcp-8443 \
  --allow tcp:8443 \
  --network default \
  --source-ranges CONTROL_PLANE_CIDR \
  --target-tags NODE_TAG

    Haz los cambios siguientes:

    • CONTROL_PLANE_CIDR: el intervalo de IPs de tu plano de control del clúster de GKE. Por ejemplo, 172.16.0.16/28.
    • NODE_TAG: etiqueta aplicada a todos los nodos de tu clúster de GKE.

    Esta regla de cortafuegos opcional es necesaria para que el webhook de Policy Controller funcione cuando tu clúster use nodos privados.

Configurar Config Connector

El Google Cloud proyecto en el que instalas Config Connector se conoce como proyecto host. Los proyectos en los que usas Config Connector para gestionar recursos se denominan proyectos gestionados. En este tutorial, usas Config Connector para crear recursos en el mismo proyecto que tu clúster de GKE, de modo que el proyecto host y el proyecto gestionado sean el mismo.Google Cloud

  1. En Cloud Shell, crea una cuenta de servicio de Google para Config Connector:

    gcloud iam service-accounts create SERVICE_ACCOUNT_NAME \
  --display-name "Config Connector Gatekeeper tutorial"

    Sustituye SERVICE_ACCOUNT_NAME por el nombre que quieras usar para esta cuenta de servicio. Por ejemplo, cnrm-gatekeeper-tutorial. Config Connector usa esta cuenta de servicio de Google para crear recursos en tu proyecto gestionado.

  2. Asigna el rol Administrador de Storage a la cuenta de servicio de Google:

    gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT \
  --member "serviceAccount:SERVICE_ACCOUNT_NAME@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com" \
  --role roles/storage.admin

    En este tutorial, usas el rol Administrador de Storage porque usas Config Connector para crear segmentos de Cloud Storage. En tu entorno, asigna los roles necesarios para gestionar los recursos que quieras crear para Config Connector. Google Cloud Para obtener más información sobre los roles predefinidos, consulta el artículo sobre la descripción de roles de la documentación de gestión de identidades y accesos.

  3. Crea un espacio de nombres de Kubernetes para los recursos de Config Connector que crearás en este tutorial:

    kubectl create namespace NAMESPACE

    Sustituye NAMESPACE por el espacio de nombres de Kubernetes que quieras usar en el tutorial. Por ejemplo, tutorial.

  4. Anota el espacio de nombres para especificar qué proyecto debe usar Config Connector para crear recursos (el proyecto gestionado): Google Cloud 

    kubectl annotate namespace NAMESPACE \
    cnrm.cloud.google.com/project-id=$GOOGLE_CLOUD_PROJECT

  5. Crea un recurso ConfigConnectorContext que habilite Config Connector para el espacio de nombres de Kubernetes y lo asocie a la cuenta de servicio de Google que has creado:

    cat << EOF | kubectl apply -f -
apiVersion: core.cnrm.cloud.google.com/v1beta1
kind: ConfigConnectorContext
metadata:
  name: configconnectorcontext.core.cnrm.cloud.google.com
  namespace: NAMESPACE
spec:
  googleServiceAccount: SERVICE_ACCOUNT_NAME@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com
EOF

    Cuando creas el recurso ConfigConnectorContext, Config Connector crea una cuenta de servicio de Kubernetes y un StatefulSet en el espacio de nombres cnrm-system para gestionar los recursos de Config Connector en tu espacio de nombres.

  6. Espera a que el pod del controlador de Config Connector de tu espacio de nombres:

    kubectl wait --namespace cnrm-system --for=condition=Ready pod \
  -l cnrm.cloud.google.com/component=cnrm-controller-manager,cnrm.cloud.google.com/scoped-namespace=NAMESPACE

    Cuando el pod esté listo, aparecerá la petición de Cloud Shell. Si recibes el mensaje error: no matching resources found, espera un minuto y vuelve a intentarlo.

  7. Vincula tu cuenta de servicio de Kubernetes de Config Connector a tu cuenta de servicio de Google creando una vinculación de política de gestión de identidades y accesos:

    gcloud iam service-accounts add-iam-policy-binding \
  SERVICE_ACCOUNT_NAME@$GOOGLE_CLOUD_PROJECT.iam.gserviceaccount.com \
  --member "serviceAccount:$GOOGLE_CLOUD_PROJECT.svc.id.goog[cnrm-system/cnrm-controller-manager-NAMESPACE]" \
  --role roles/iam.workloadIdentityUser

    Este enlace permite que la cuenta de servicio de cnrm-controller-manager-NAMESPACE Kubernetes del espacio de nombres cnrm-system actúe como la cuenta de servicio de Google que has creado.

Instalar Policy Controller

Instala Policy Controller siguiendo las instrucciones de instalación.

Usa un intervalo de auditoría de 60 segundos.

Crear un Google Cloud recurso con Config Connector

  1. En Cloud Shell, crea un manifiesto de Config Connector que represente un segmento de Cloud Storage en la región us-central1:

    cat << EOF > tutorial-storagebucket-us-central1.yaml
apiVersion: storage.cnrm.cloud.google.com/v1beta1
kind: StorageBucket
metadata:
  name: tutorial-us-central1-$GOOGLE_CLOUD_PROJECT
  namespace: NAMESPACE
spec:
  location: us-central1
  uniformBucketLevelAccess: true
EOF

  2. Para crear el segmento de Cloud Storage, aplica el manifiesto:

    kubectl apply -f tutorial-storagebucket-us-central1.yaml

  3. Verifica que Config Connector haya creado el segmento de Cloud Storage:

    gcloud storage ls | grep tutorial

    El resultado debería ser similar al siguiente:

    gs://tutorial-us-central1-PROJECT_ID/

    Este resultado incluye PROJECT_ID, que es el ID de tu proyecto. Google Cloud

    Si no ves este resultado, espera un minuto y vuelve a realizar el paso.

Crear una política

Una política de Policy Controller consta de una plantilla de restricción y una restricción. La plantilla de restricciones contiene la lógica de la política. La restricción especifica dónde se aplica la política y los parámetros de entrada de la lógica de la política.

  1. En Cloud Shell, crea una plantilla de restricción que limite las ubicaciones de los segmentos de Cloud Storage:

    cat << EOF > tutorial-storagebucket-location-template.yaml
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: gcpstoragelocationconstraintv1
spec:
  crd:
    spec:
      names:
        kind: GCPStorageLocationConstraintV1
      validation:
        openAPIV3Schema:
          properties:
            locations:
              type: array
              items:
                type: string
            exemptions:
              type: array
              items:
                type: string
  targets:
  - target: admission.k8s.gatekeeper.sh
    rego: |
      package gcpstoragelocationconstraintv1

      allowedLocation(reviewLocation) {
          locations := input.parameters.locations
          satisfied := [ good | location = locations[_]
                                good = lower(location) == lower(reviewLocation)]
          any(satisfied)
      }

      exempt(reviewName) {
          input.parameters.exemptions[_] == reviewName
      }

      violation[{"msg": msg}] {
          bucketName := input.review.object.metadata.name
          bucketLocation := input.review.object.spec.location
          not allowedLocation(bucketLocation)
          not exempt(bucketName)
          msg := sprintf("Cloud Storage bucket <%v> uses a disallowed location <%v>, allowed locations are %v", [bucketName, bucketLocation, input.parameters.locations])
      }

      violation[{"msg": msg}] {
          not input.parameters.locations
          bucketName := input.review.object.metadata.name
          msg := sprintf("No permitted locations provided in constraint for Cloud Storage bucket <%v>", [bucketName])
      }
EOF

  2. Aplica la plantilla para crear el segmento de Cloud Storage:

    kubectl apply -f tutorial-storagebucket-location-template.yaml

  3. Crea una restricción que solo permita los contenedores de las regiones de Singapur y Yakarta (asia-southeast1 y asia-southeast2). La restricción se aplica al espacio de nombres que has creado anteriormente. Exime al segmento de Cloud Storage predeterminado de Cloud Build.

    cat << EOF > tutorial-storagebucket-location-constraint.yaml
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: GCPStorageLocationConstraintV1
metadata:
  name: singapore-and-jakarta-only
spec:
  enforcementAction: deny
  match:
    kinds:
    - apiGroups:
      - storage.cnrm.cloud.google.com
      kinds:
      - StorageBucket
    namespaces:
    - NAMESPACE
  parameters:
    locations:
    - asia-southeast1
    - asia-southeast2
    exemptions:
    - ${GOOGLE_CLOUD_PROJECT}_cloudbuild
EOF

  4. Para limitar las zonas en las que pueden existir los contenedores, aplica la siguiente restricción:

    kubectl apply -f tutorial-storagebucket-location-constraint.yaml

Verificar la política

  1. Crea un manifiesto que represente un segmento de Cloud Storage en una ubicación no permitida (us-west1):

    cat << EOF > tutorial-storagebucket-us-west1.yaml
apiVersion: storage.cnrm.cloud.google.com/v1beta1
kind: StorageBucket
metadata:
  name: tutorial-us-west1-$GOOGLE_CLOUD_PROJECT
  namespace: NAMESPACE
spec:
  location: us-west1
  uniformBucketLevelAccess: true
EOF

  2. Para crear el segmento de Cloud Storage, aplica el manifiesto:

    kubectl apply -f tutorial-storagebucket-us-west1.yaml

    El resultado debería ser similar al siguiente:

    Error from server ([singapore-and-jakarta-only] Cloud Storage bucket
<tutorial-us-west1-PROJECT_ID> uses a disallowed location
<us-west1>, allowed locations are ["asia-southeast1",
"asia-southeast2"]): error when creating
"tutorial-storagebucket-us-west1.yaml": admission webhook
"validation.gatekeeper.sh" denied the request: [singapore-and-jakarta-only]
Cloud Storage bucket <tutorial-us-west1-PROJECT_ID> uses a
disallowed location <us-west1>, allowed locations are
["asia-southeast1", "asia-southeast2"]

  3. Opcional: Puedes ver un registro de la decisión de denegar la solicitud en los registros de auditoría de Cloud. Consulta los registros de actividad de administración de tu proyecto:

    gcloud logging read --limit=1 \
    "logName=\"projects/$GOOGLE_CLOUD_PROJECT/logs/cloudaudit.googleapis.com%2Factivity\""'
    resource.type="k8s_cluster"
    resource.labels.cluster_name="CLUSTER_NAME"
    resource.labels.location="ZONE"
    protoPayload.authenticationInfo.principalEmail!~"system:serviceaccount:cnrm-system:.*"
    protoPayload.methodName:"com.google.cloud.cnrm."
    protoPayload.status.code=7'

    El resultado debería ser similar al siguiente:

    insertId: 3c6940bb-de14-4d18-ac4d-9a6becc70828
labels:
  authorization.k8s.io/decision: allow
  authorization.k8s.io/reason: ''
  mutation.webhook.admission.k8s.io/round_0_index_0: '{"configuration":"mutating-webhook.cnrm.cloud.google.com","webhook":"container-annotation-handler.cnrm.cloud.google.com","mutated":true}'
  mutation.webhook.admission.k8s.io/round_0_index_1: '{"configuration":"mutating-webhook.cnrm.cloud.google.com","webhook":"management-conflict-annotation-defaulter.cnrm.cloud.google.com","mutated":true}'
logName: projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity
operation:
  first: true
  id: 3c6940bb-de14-4d18-ac4d-9a6becc70828
  last: true
  producer: k8s.io
protoPayload:
  '@type': type.googleapis.com/google.cloud.audit.AuditLog
  authenticationInfo:
    principalEmail: user@example.com
  authorizationInfo:
  - permission: com.google.cloud.cnrm.storage.v1beta1.storagebuckets.create
    resource: storage.cnrm.cloud.google.com/v1beta1/namespaces/NAMESPACE/storagebuckets/tutorial-us-west1-PROJECT_ID
  methodName: com.google.cloud.cnrm.storage.v1beta1.storagebuckets.create
  requestMetadata:
    callerIp: 203.0.113.1
    callerSuppliedUserAgent: kubectl/v1.21.1 (linux/amd64) kubernetes/5e58841
  resourceName: storage.cnrm.cloud.google.com/v1beta1/namespaces/NAMESPACE/storagebuckets/tutorial-us-west1-PROJECT_ID
  serviceName: k8s.io
  status:
    code: 7
    message: Forbidden
receiveTimestamp: '2021-05-21T06:56:24.940264678Z'
resource:
  labels:
    cluster_name: CLUSTER_NAME
    location: CLUSTER_ZONE
    project_id: PROJECT_ID
  type: k8s_cluster
timestamp: '2021-05-21T06:56:09.060635Z'

    El campo methodName muestra la operación que se ha intentado, el campo resourceName muestra el nombre completo del recurso de Config Connector y la sección status muestra que la solicitud no se ha completado correctamente, con el código de error 7 y el mensaje Forbidden.

  4. Crea un manifiesto que represente un segmento de Cloud Storage en una ubicación permitida (asia-southeast1):

    cat << EOF > tutorial-storagebucket-asia-southeast1.yaml
apiVersion: storage.cnrm.cloud.google.com/v1beta1
kind: StorageBucket
metadata:
  name: tutorial-asia-southeast1-$GOOGLE_CLOUD_PROJECT
  namespace: NAMESPACE
spec:
  location: asia-southeast1
  uniformBucketLevelAccess: true
EOF

  5. Para crear el segmento de Cloud Storage, aplica el manifiesto:

    kubectl apply -f tutorial-storagebucket-asia-southeast1.yaml

    El resultado debería ser similar al siguiente:

    storagebucket.storage.cnrm.cloud.google.com/tutorial-asia-southeast1-PROJECT_ID created

    Este resultado incluye PROJECT_ID, que es el ID de tu proyecto. Google Cloud

  6. Comprueba que Config Connector haya creado el segmento de Cloud Storage:

    gcloud storage ls | grep tutorial

    El resultado debería ser similar al siguiente:

    gs://tutorial-asia-southeast1-PROJECT_ID/
gs://tutorial-us-central1-PROJECT_ID/

    Si no ves este resultado, espera un minuto y vuelve a realizar este paso.

Restricciones de auditoría

El controlador de auditoría de Policy Controller evalúa periódicamente los recursos en función de sus restricciones. El controlador detecta infracciones de políticas en los recursos creados antes de la restricción y en los recursos creados fuera de Config Connector.

  1. En Cloud Shell, consulta las infracciones de todas las restricciones que usen la plantilla de restricción GCPStorageLocationConstraintV1:

    kubectl get gcpstoragelocationconstraintv1 -o json \
  | jq '.items[].status.violations'

    El resultado debería ser similar al siguiente:

    [
  {
    "enforcementAction": "deny",
    "kind": "StorageBucket",
    "message": "Cloud Storage bucket <tutorial-us-central1-PROJECT_ID>
    uses a disallowed location <us-central1>, allowed locations are
    \"asia-southeast1\", \"asia-southeast2\"",
    "name": "tutorial-us-central1-PROJECT_ID",
    "namespace": "NAMESPACE"
  }
]

    Verás el segmento de Cloud Storage que has creado us-central1 antes de crear la restricción.

Validar recursos durante el desarrollo

Durante el desarrollo y las compilaciones de integración continua, es útil validar los recursos con respecto a las restricciones antes de aplicarlos al clúster de GKE. La validación proporciona comentarios rápidos y te permite descubrir problemas con los recursos y las restricciones en una fase temprana. En estos pasos se muestra cómo validar recursos con kpt. La herramienta de línea de comandos kpt te permite gestionar y aplicar manifiestos de recursos de Kubernetes.

  1. En Cloud Shell, ejecuta la gatekeeper función KRM con kpt:

    kpt fn eval . --image=gcr.io/kpt-fn/gatekeeper:v0.2 --truncate-output=false

    Una función de KRM es un programa que puede mutar o validar recursos de Kubernetes almacenados en el sistema de archivos local como archivos YAML. La función gatekeeper KRM valida los recursos de los segmentos de Cloud Storage de Config Connector con la política de Gatekeeper. La función gatekeeper KRM se empaqueta como una imagen de contenedor disponible en Artifact Registry.

    La función informa de que los archivos de manifiesto de los segmentos de Cloud Storage de las regiones us-central1 y us-west1 infringen la restricción.

    El resultado debería ser similar al siguiente:

    [RUNNING] "gcr.io/kpt-fn/gatekeeper:v0.2"
[FAIL] "gcr.io/kpt-fn/gatekeeper:v0.2"
  Results:
    [ERROR] Cloud Storage bucket <tutorial-us-central1-PROJECT_ID> uses a disallowed location <us-central1>, allowed locations are ["asia-southeast1", "asia-southeast2"] violatedConstraint: singapore-and-jakarta-only in object "storage.cnrm.cloud.google.com/v1beta1/StorageBucket/tutorial/tutorial-us-central1-GOOGLE_CLOUD_PROJECT" in file "tutorial-storagebucket-us-central1.yaml"
    [ERROR] Cloud Storage bucket <tutorial-us-west1-PROJECT_ID> uses a disallowed location <us-west1>, allowed locations are ["asia-southeast1", "asia-southeast2"] violatedConstraint: singapore-and-jakarta-only in object "storage.cnrm.cloud.google.com/v1beta1/StorageBucket/tutorial/tutorial-us-west1-GOOGLE_CLOUD_PROJECT" in file "tutorial-storagebucket-us-west1.yaml"
  Stderr:
    "[error] storage.cnrm.cloud.google.com/v1beta1/StorageBucket/test/tutorial-us-central1-PROJECT_ID : Cloud Storage bucket <tutorial-us-central1-PROJECT_ID> uses a disallowed location <us-central1>, allowed locations are [\"asia-southeast1\", \"asia-southeast2\"]"
    "violatedConstraint: singapore-and-jakarta-only"
    ""
    "[error] storage.cnrm.cloud.google.com/v1beta1/StorageBucket/test/tutorial-us-west1-PROJECT_IDT : Cloud Storage bucket <tutorial-us-west1-PROJECT_IDgt; uses a disallowed location <us-west1>, allowed locations are [\"asia-southeast1\", \"asia-southeast2\"]"
    "violatedConstraint: singapore-and-jakarta-only"
    ""
  Exit code: 1

Validar recursos creados fuera de Config Connector

Puedes validar los recursos que se hayan creado fuera de Config Connector exportándolos. Google Cloud Después de exportar los recursos, utilice una de las siguientes opciones para evaluar sus políticas de Policy Controller en comparación con los recursos exportados:

  • Valida los recursos con la función gatekeeper de KRM.

  • Importa los recursos en Config Connector.

Para exportar los recursos, utilice Inventario de Recursos de Cloud.

  1. En Cloud Shell, habilita la API Cloud Asset:

    gcloud services enable cloudasset.googleapis.com

  2. Elimina los archivos de manifiesto de recursos de Kubernetes de los contenedores de Cloud Storage en us-central1 y us-west1:

    rm tutorial-storagebucket-us-*.yaml

  3. Exporta todos los recursos de Cloud Storage de tu proyecto actual y almacena el resultado en un archivo llamado export.yaml:

    gcloud beta resource-config bulk-export \
  --project $GOOGLE_CLOUD_PROJECT \
  --resource-format krm \
  --resource-types StorageBucket > export.yaml

    El resultado debería ser similar al siguiente:

    Exporting resource configurations to stdout...

Export complete.

  4. Crea un flujo de procesamiento de kpt encadenando funciones de KRM. Esta canalización valida los recursos del directorio actual con la política de ubicación del segmento de Cloud Storage:

    kpt fn source . \
  | kpt fn eval - --image=gcr.io/kpt-fn/set-namespace:v0.1 -- namespace=NAMESPACE \
  | kpt fn eval - --image=gcr.io/kpt-fn/gatekeeper:v0.2 --truncate-output=false

    Los recursos exportados no tienen ningún valor para el atributo de metadatos namespace. Esta canalización usa una función de KRM llamada set-namespace para definir el valor namespace de todos los recursos.

    El resultado es similar al siguiente y muestra infracciones de los recursos que ha exportado:

    [RUNNING] "gcr.io/kpt-fn/set-namespace:v0.1"
[PASS] "gcr.io/kpt-fn/set-namespace:v0.1"
[RUNNING] "gcr.io/kpt-fn/gatekeeper:v0.2"
[FAIL] "gcr.io/kpt-fn/gatekeeper:v0.2"
  Results:
    [ERROR] Cloud Storage bucket <tutorial-us-central1-PROJECT_ID> uses a disallowed location <us-central1>, allowed locations are ["asia-southeast1", "asia-southeast2"] violatedConstraint: singapore-and-jakarta-only in object "storage.cnrm.cloud.google.com/v1beta1/StorageBucket/tutorial/tutorial-us-central1-GOOGLE_CLOUD_PROJECT" in file "export.yaml"
  Stderr:
    "[error] storage.cnrm.cloud.google.com/v1beta1/StorageBucket/test/tutorial-us-central1-PROJECT_ID : Cloud Storage bucket <tutorial-us-central1-PROJECT_ID> uses a disallowed location <us-central1>, allowed locations are [\"asia-southeast1\", \"asia-southeast2\"]"
    "violatedConstraint: singapore-and-jakarta-only"
    ""
  Exit code: 1

    Si tu proyecto de Google Cloud contiene segmentos de Cloud Storage que creaste antes de empezar este tutorial y su ubicación infringe la restricción, los segmentos creados anteriormente aparecerán en el resultado.

Enhorabuena, has configurado correctamente una política que rige la ubicación permitida de los segmentos de Cloud Storage. El tutorial se ha completado. Ahora puedes seguir añadiendo tus propias políticas para otros recursos de Google Cloud.

Solución de problemas

Si Config Connector no crea los recursos esperados, Google Cloud usa el siguiente comando en Cloud Shell para ver los registros del gestor de controladores de Config Connector:

kubectl logs --namespace cnrm-system --container manager \
  --selector cnrm.cloud.google.com/component=cnrm-controller-manager,cnrm.cloud.google.com/scoped-namespace=NAMESPACE

Si Policy Controller no aplica las políticas correctamente, usa el siguiente comando para ver los registros del gestor de controladores:

kubectl logs deployment/gatekeeper-controller-manager \
  --namespace gatekeeper-system

Si Policy Controller no informa de infracciones en el campo status de los objetos de restricción, consulta los registros del controlador de auditoría con este comando:

kubectl logs deployment/gatekeeper-audit --namespace gatekeeper-system

Si tienes otros problemas con este tutorial, te recomendamos que consultes estos documentos: