Crea restricciones de CAI

Antes de comenzar

• Crea una biblioteca de políticas.

Constraint Framework

gcloud beta terraform vet usa políticas de Constraint Framework, que constan de restricciones y plantillas de restricciones. La diferencia entre ambas es la siguiente:

• Una plantilla de restricciones es como una declaración de función. Define una regla en Rego y, de forma opcional, toma parámetros de entrada.
• Una restricción es un archivo que hace referencia a una plantilla de restricciones y define los parámetros de entrada para pasarla a ella y los recursos que cubre la política.

Esto te permite evitar la repetición. Puedes escribir una plantilla de restricciones con una política genérica y, luego, escribir cualquier cantidad de restricciones que proporcionen diferentes parámetros de entrada o reglas de coincidencia de recursos.

Comparación entre los recursos de CAI y los de Terraform

Los recursos de Cloud Asset Inventory son un formato de exportación de datos estándar de Google que está disponible para muchos recursos de Google Cloud. Los datos de CAI solo están disponibles después de crear o actualizar un recurso. Sin embargo, mediante la conversión de los cambios de recursos de Terraform a los datos de elementos de CAI, gcloud beta terraform vet te permite escribir una política una vez y usarla antes de aplicarla y como una verificación de auditoría con herramientas compatibles.

Herramientas compatibles

Las siguientes herramientas no son productos oficiales de Google y no son compatibles. Sin embargo, pueden ser compatibles con las políticas escritas para gcloud beta terraform vet.

• Cuadro de evaluación de CFT
• Forseti

Crea una plantilla de restricción

Antes de desarrollar tu plantilla de restricciones, verifica que el recurso para el que deseas escribir una política sea compatible con Cloud Asset Inventory y gcloud beta terraform vet..

Para crear una plantilla de restricciones, sigue estos pasos:

1. Recopila datos de muestra.
2. Escribe Rego.
3. Prueba tu Rego.
4. Configura un esqueleto de plantilla de restricciones.
5. Intercala tu Rego.
6. Configura una restricción.

Recopila datos de muestra

Para escribir una plantilla de restricciones, debes tener datos de muestra con los cuales operar. Las restricciones basadas en CAI operan con datos de elementos de CAI. Para recopilar datos de muestra, crea recursos del tipo adecuado y expórtalos como JSON, como se describe en la Guía de inicio rápido de CAI.

Este es un ejemplo de exportación JSON para una dirección de Compute:

[
  {
    "name": "//compute.googleapis.com/projects/789/regions/us-central1/addresses/my-internal-address",
    "asset_type": "compute.googleapis.com/Address",
    "ancestors: [
      "organization/123",
      "folder/456",
      "project/789"
    ],
    "resource": {
      "version": "v1",
      "discovery_document_uri": "https://www.googleapis.com/discovery/v1/apis/compute/v1/rest",
      "discovery_name": "Address",
      "parent": "//cloudresourcemanager.googleapis.com/projects/789",
      "data": {
        "address": "10.0.42.42",
        "addressType": "INTERNAL",
        "name": "my-internal-address",
        "region": "projects/789/global/regions/us-central1"
      }
    }
  },
]

Escribe Rego

Una vez que tengas los datos de muestra, puedes escribir la lógica para la plantilla de restricciones en Rego. Tu Rego debe tener una regla violations. El elemento que se revisa está disponible como input.review. Los parámetros de restricción están disponibles como input.parameters. Por ejemplo, para requerir que los elementos compute.googleapis.com/Address tengan un addressType permitido, escribe lo siguiente:

# validator/gcp_compute_address_address_type_allowlist_constraint_v1.rego
package templates.gcp.GCPComputeAddressAddressTypeAllowlistConstraintV1

violation[{
  "msg": message,
  "details": metadata,
}] {
  asset := input.review
  asset.asset_type == "compute.googleapis.com/Address"

  allowed_address_types := input.parameters.allowed_address_types
  count({asset.resource.data.addressType} & allowed_address_types) >= 1
  message := sprintf(
    "Compute address %s has a disallowed address_type: %s",
    [asset.name, asset.resource.data.addressType]
  )
  metadata := {"asset": asset.name}
}

Asigna un nombre a la plantilla de restricción

En el ejemplo anterior, se usa el nombre GCPComputeAddressAddressTypeAllowlistConstraintV1. Este es un identificador único para cada plantilla de restricciones. Recomendamos seguir estos lineamientos para asignar nombres:

• Formato general: GCP{resource}{feature}Constraint{version}. Usa CamelCase. (En otras palabras, usa mayúsculas cada palabra nueva).
• Para restricciones de recursos únicos, sigue los nombres de grupos de gcloud a fin de asignar nombres a recursos. Por ejemplo, usa “compute” en lugar de “gce”, “sql” en lugar de “cloud-sql” y “container-cluster” en lugar de “gke”.
• Si una plantilla se aplica a más de un tipo de recurso, omite la parte del recurso y solo incluye la función (ejemplo: "GCPAddressTypeAllowlistConstraintV1").
• El número de versión no sigue el formulario semver; es solo un número. Esto hace que efectivamente cada versión de una plantilla sea única.

Recomendamos usar un nombre para el archivo Rego que coincida con el nombre de la plantilla de restricción, pero con snake_case. En otras palabras, convierte el nombre en palabras en minúscula separadas con _. Para el ejemplo anterior, el nombre de archivo recomendado es gcp_compute_address_address_type_allowlist_constraint_v1.rego

Prueba tu Rego

Puedes probar tu Rego de forma manual con Rego Playground. Asegúrate de usar datos no sensibles.

Te recomendamos escribir pruebas automatizadas. Coloca los datos de muestra recopilados en validator/test/fixtures/<constraint filename>/assets/data.json y haz referencia a ellos en el archivo de prueba de la siguiente manera:

# validator/gcp_compute_address_address_type_allowlist_constraint_v1_test.rego
package templates.gcp.GCPComputeAddressAddressTypeAllowlistConstraintV1

import data.test.fixtures.gcp_compute_address_address_type_allowlist_constraint_v1_test.assets as assets

test_violation_with_disallowed_address_type {
  parameters := {
    "allowed_address_types": "EXTERNAL"
  }
  violations := violation with input.review as assets[_]
    with input.parameters as parameters
  count(violations) == 1
}

Coloca tu Rego y tu prueba en la carpeta validator en tu biblioteca de políticas.

Configura un esqueleto de plantilla de restricciones

Una vez que tengas una regla de Rego que funcione y esté probada, debes empaquetarla como una plantilla de restricción. Constraint Framework usa las definiciones de recursos personalizados de Kubernetes como el contenedor para el Rego de la política.

La plantilla de restricciones también define qué parámetros están permitidos como entradas de restricciones, mediante el esquema OpenAPI V3.

Usa para el esqueleto el mismo nombre que usaste para el Rego. En particular:

• Usa el mismo nombre de archivo que tu Rego. Ejemplo: gcp_compute_address_address_type_allowlist_constraint_v1.yaml
• spec.crd.spec.names.kind debe contener el nombre de la plantilla.
• metadata.name debe contener el nombre de la plantilla, pero en minúsculas.

Coloca el esqueleto de la plantilla de restricción en policies/templates.

Para el ejemplo anterior:

# policies/templates/gcp_compute_address_address_type_allowlist_constraint_v1.yaml
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: gcpcomputeaddressaddresstypeallowlistconstraintv1
spec:
  crd:
    spec:
      names:
        kind: GCPComputeAddressAddressTypeAllowlistConstraintV1
      validation:
        openAPIV3Schema:
          properties:
            allowed_address_types:
              description: "A list of address_types allowed, for example: ['INTERNAL']"
              type: array
              items:
                type: string
  targets:
    - target: validation.gcp.forsetisecurity.org
      rego: |
            #INLINE("validator/gcp_compute_address_address_type_allowlist_constraint_v1.rego")
            #ENDINLINE

Intercala tu Rego

En este punto, según el ejemplo anterior, el diseño de tu directorio se ve de la siguiente manera:

| policy-library/
|- validator/
||- gcp_compute_address_address_type_allowlist_constraint_v1.rego
||- gcp_compute_address_address_type_allowlist_constraint_v1_test.rego
|- policies
||- templates
|||- gcp_compute_address_address_type_allowlist_constraint_v1.yaml

Si clonaste el repositorio de bibliotecas de políticas proporcionado por Google, puedes ejecutar make build para actualizar de manera automática tus plantillas de restricciones en policies/templates con el Rego definido en validator.

Configura una restricción

Las restricciones contienen tres datos que gcloud beta terraform vet necesita para aplicar y denunciar los incumplimientos de forma correcta:

• severity: low, medium o high
• match: parámetros para determinar si una restricción se aplica a un recurso en particular. Se admiten los siguientes parámetros de coincidencia:
  • ancestries: una lista de rutas de principales para incluir con coincidencias de estilo glob
  • excludedAncestries: (opcional) una lista de rutas de principales para excluir mediante coincidencias de estilo glob.
• parameters: valores para los parámetros de entrada de la plantilla de restricción.

Asegúrate de que kind contenga el nombre de la plantilla de restricción. Recomendamos configurar metadata.name como una slug descriptiva.

Por ejemplo, para permitir solo tipos de direcciones INTERNAL con la plantilla de restricción del ejemplo anterior, escribe lo siguiente:

# policies/constraints/gcp_compute_address_internal_only.yaml
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: GCPComputeAddressAddressTypeAllowlistConstraintV1
metadata:
  name: gcp_compute_address_internal_only
spec:
  severity: high
  match:
    ancestries:
    - "**"
  parameters:
    allowed_address_types:
    - "INTERNAL"

Ejemplos de coincidencias:

Si una dirección de recurso coincide con los valores de ancestries y excludedAncestries, se excluye.

Limitaciones

Los datos del plan de Terraform proporcionan la mejor representación disponible del estado real después de aplicarlo. Sin embargo, en muchos casos, es posible que el estado después de aplicar no se conozca porque se calcula en el lado del servidor. En estos casos, los datos tampoco están disponibles en los elementos de CAI convertidos.

Compilar rutas de principales de CAI es parte del proceso cuando se validan políticas. Usa el proyecto predeterminado que se proporciona para evitar los ID de proyectos desconocidos. En el caso de que no se proporcione un proyecto predeterminado, la ruta principal se establece de forma predeterminada en organizations/unknown.

Para inhabilitar una entidad principal desconocida, agrega la siguiente restricción:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: GCPAlwaysViolatesConstraintV1
metadata:
  name: disallow_unknown_ancestry
  annotations:
    description: |
      Unknown ancestry is not allowed; use --project=<project> to set a
      default ancestry
spec:
  severity: high
  match:
    ancestries:
    - "organizations/unknown"
  parameters: {}

Recursos admitidos

Si deseas que gcloud beta terraform vet agregue compatibilidad con un recurso que no está en esta lista, abre una solicitud de mejora y considera contribuir con código.

La lista de recursos compatibles depende de la versión de gcloud beta terraform vet que esté instalada. La lista actual de recursos compatibles es la siguiente: