Reglas de entrada y salida

En esta página, se explican las reglas de entrada y salida para los Controles del servicio de VPC. Los Controles del servicio de VPC usan reglas de entrada y salida para permitir el acceso desde y hacia los recursos y clientes protegidos por los perímetros de servicio.

Los bloques de reglas de entrada y salida especifican la dirección del acceso permitido desde y hacia las diferentes identidades y recursos. Las reglas de entrada y salida pueden reemplazar y simplificar los casos de uso que antes requerían uno o más puentes perimetrales.

Para obtener información sobre cómo aplicar políticas de entrada y salida a tu perímetro de servicio, consulta Configura políticas de entrada y salida.

Puedes configurar identidades de terceros y grupos de identidades (Versión preliminar) en las reglas de entrada y salida. Para ver un caso de uso de ejemplo, consulta Ejemplo del uso de grupos de identidad e identidades de terceros en reglas de entrada y salida.

Para obtener una lista de casos de uso y muestras de intercambio seguro de datos, consulta Intercambio seguro de datos con reglas de entrada y salida.

Para obtener una lista de casos de uso y muestras de acceso adaptado al contexto, consulta Acceso adaptado al contexto con reglas de entrada.

Beneficios de las reglas de entrada y salida

1. Las reglas de entrada y salida te permiten intercambiar datos de forma privada y eficiente entre organizaciones y dentro de ellas a través de las API del servicio de Google Cloud.
2. Las reglas de entrada y salida te permiten otorgar acceso a los recursos de Google Cloud en un perímetro según el contexto de la solicitud a la API:
   1. Restringe los tipos de identidad o las identidades que se pueden usar según la red de origen, la dirección IP o el dispositivo.
   2. Restringe las API y los métodos de Google Cloud a los que se puede acceder según la red de origen, la dirección IP, el dispositivo y el tipo de identidad.
3. Minimiza el riesgo de robo mediante la limitación del servicio, los métodos, las identidades y los proyectos de Google Cloud, las redes de VPC y los servicios exactos que se usan para ejecutar el intercambio de datos.
4. Otorga acceso de solo lectura a las imágenes y conjuntos de datos externos que no administras.
5. Asegúrate de que los clientes de segmentos menos privilegiados no tengan acceso a los recursos de Google Cloud en segmentos más privilegiados, al mismo tiempo que permite el acceso en la otra dirección.
6. Simplifica las configuraciones que anteriormente requerían uno o más puentes perimetrales.

Definición de entrada y salida

Las definiciones de entrada y salida son independientes de la operación que se invoca en el recurso. Por lo tanto, las definiciones hacen referencia a la dirección de la solicitud y no a la dirección del movimiento de datos.

• Entrada: Se refiere a cualquier acceso de un cliente de la API desde fuera del perímetro de servicio a los recursos dentro del perímetro de servicio. Ejemplo:

  • Un cliente de Cloud Storage fuera de un perímetro de servicio que llama a operaciones de lectura, escritura o copia de Cloud Storage en un recurso de Cloud Storage dentro del perímetro.

• Salida: Se refiere a cualquier acceso que incluya un cliente de API o recursos dentro del perímetro de servicio y recursos fuera del perímetro de servicio. Ejemplos:

  • Un cliente de Compute Engine dentro de un perímetro de servicio que llama a una operación create de Compute Engine en la que el recurso de imagen está fuera del perímetro.
  • Un cliente de Cloud Storage, dentro o fuera del perímetro, llama a un comando copy en el que un bucket está dentro del perímetro y el otro está fuera de él.

Nota: Los Controles del servicio de VPC permiten el acceso a algunos recursos administrados por Google, independientemente de las restricciones que apliquen las políticas de entrada o salida. Por ejemplo, Container Registry puede acceder al repositorio gcr.io/cloud-dataflow de solo lectura administrado por Google, independientemente de las restricciones que aplique el perímetro de servicio.

Modelo de políticas

Una regla de entrada o salida consta de bloques from y to en los que ocurre lo siguiente:

• from hace referencia a los atributos del cliente de API.
• to hace referencia a los atributos de los servicios y recursos de Google Cloud.

Se pueden asociar varias reglas de entrada y salida a un perímetro de servicio. Se permite o rechaza una llamada del servicio de Google Cloud según las siguientes semánticas:

• Se permite una solicitud de un cliente fuera del perímetro a un recurso de Google Cloud dentro del perímetro si se cumplen las condiciones de la regla de entrada necesaria.
• Se permite una solicitud de un cliente dentro del perímetro a un recurso de Google Cloud fuera del perímetro si se cumplen las condiciones de la regla de salida necesaria.
• Se permiten una llamada a la API que involucra un recurso de Google Cloud dentro del perímetro y un recurso de Google Cloud fuera del perímetro si hay una regla de entrada que cumple el cliente (si el cliente no está dentro del perímetro) y una regla de salida que cumpla el recurso externo.

Ejemplos de solicitudes a la API que permiten las reglas de entrada

• Un cliente de Cloud Storage fuera del perímetro descarga objetos de un bucket de Cloud Storage dentro del perímetro a la máquina local (por ejemplo, mediante el comando gcloud storage cp).
• Un cliente de BigQuery fuera del perímetro usa un trabajo de BigQuery en un proyecto dentro del perímetro para consultar un conjunto de datos de BigQuery dentro del perímetro (por ejemplo, mediante el comando bq query)
• Una VM de Compute Engine en una red de VPC que está fuera del perímetro escribe en un bucket de Cloud Storage dentro del perímetro.

Ejemplos de solicitudes a la API que permiten las reglas de salida

• Un cliente de Cloud Storage dentro del perímetro copia los objetos entre un bucket de Cloud Storage fuera del perímetro y un bucket dentro del perímetro (por ejemplo, con el comando gcloud storage cp).

Nota: En este ejemplo, la misma regla de salida permite copiar objetos de Cloud Storage en ambas direcciones. Las reglas de entrada y salida son independientes de la semántica de la solicitud a la API y de la dirección del movimiento de datos.

• Un cliente de BigQuery dentro del perímetro usa un trabajo de BigQuery en un proyecto fuera del perímetro para consultar un conjunto de datos de BigQuery dentro del perímetro (por ejemplo, mediante el comando bq query).

Ejemplos de solicitudes a la API que se permiten mediante la combinación de reglas de entrada y salida

• Un cliente de Cloud Storage fuera del perímetro copia objetos entre un bucket de Cloud Storage fuera del perímetro y un bucket dentro del perímetro (por ejemplo, con el comando gcloud storage cp).
• Un cliente de BigQuery fuera del perímetro usa un trabajo de BigQuery en un proyecto fuera del perímetro para consultar un conjunto de datos de BigQuery dentro del perímetro (por ejemplo, con el comando bq query)
• Un cliente de Compute Engine fuera del perímetro que crea un disco de Compute Engine fuera del perímetro con una clave de Cloud KMS dentro del perímetro

Nota: En este ejemplo, la regla de salida se debe crear en el perímetro que contiene el proyecto que contiene la clave de Cloud KMS. La regla de salida debe permitir el acceso al servicio compute.googleapis.com y al método compute.v1.ImagesService.Insert.

En los ejemplos de BigQuery y Compute Engine, una regla de entrada no es suficiente, ya que el trabajo de BigQuery o el disco de Compute Engine están fuera del perímetro. Se requiere una regla de salida para permitir una solicitud a la API que involucre un recurso de Google Cloud dentro del perímetro (el conjunto de datos de BigQuery o la clave de Cloud KMS) y un recurso fuera del perímetro (el trabajo de BigQuery o el disco de Compute Engine).

Solicitudes a la API que involucran varios perímetros de servicio

Cuando los recursos a los que se accede o el cliente de API pertenecen a diferentes perímetros de servicio, las políticas de todos los perímetros involucrados deben permitir la solicitud a la API. Por ejemplo, considera un cliente y un bucket de Cloud Storage a dentro de un perímetro de servicio A y un bucket b dentro de un perímetro de servicio B. En este ejemplo, para que el cliente de Cloud Storage copie objetos del bucket a al bucket b y del bucket b al bucket a, se requieren las siguientes reglas de entrada y salida:

• una regla de salida en el perímetro A para permitir el acceso al bucket de Cloud Storage b ,
• una regla de salida en el perímetro B para permitir el acceso al bucket de Cloud Storage a
• una regla de entrada en el perímetro B para permitir el acceso al cliente de Cloud Storage que está fuera del perímetro B.

Referencia de reglas de entrada

Las reglas de entrada se pueden configurar con la consola de Google Cloud, un archivo JSON o un archivo YAML. En el siguiente ejemplo, se usa el formato .yaml:

- ingressFrom:
    identityType: ANY_IDENTITY | ANY_USER_ACCOUNT | ANY_SERVICE_ACCOUNT
    *OR*
    identities:
    - PRINCIPAL_IDENTIFIER
    sources:
    - resource: RESOURCE
      *OR*
    - accessLevel: ACCESS_LEVEL
  ingressTo:
    operations:
    - serviceName: SERVICE
      methodSelectors:
      - method: METHOD
      *OR*
      - permission: PERMISSION
    resources:
    - projects/PROJECT

• - ingressFrom:: Inicia el bloque from, que enumera las identidades y las fuentes permitidas fuera del perímetro (obligatorio).

• identityType:: - (Se debe usar este atributo o el atributo identities) Este atributo define los tipos de identidades que se pueden usar desde las sourcesespecificadas (origen de la red). Valores aceptables: ANY_IDENTITY, ANY_USER_ACCOUNT, ANY_SERVICE_ACCOUNT. ANY_IDENTITY permite todas las identidades. ANY_USER_ACCOUNT permite a todos los usuarios humanos. ANY_SERVICE_ACCOUNT permite todas las cuentas de servicio.

  Este atributo no restringe las identidades en función de la organización. Por ejemplo, ANY_SERVICE_ACCOUNT permite una cuenta de servicio de cualquier organización.

• identities:: (Se debe usar este atributo o el atributo identityType) Este atributo inicia una lista de cuentas de servicio, cuentas de usuario, Grupos de Google o identidades de terceros que pueden acceder a los recursos del perímetro.

• PRINCIPAL_IDENTIFIER: Especifica una cuenta de usuario, una cuenta de servicio, un Grupo de Google o una identidad de terceros a la que deseas proporcionar acceso a los recursos del perímetro. Usa el formato especificado en Identificadores principales de la API de v1 IAM. Por ejemplo, usa el formato group:[e-mail] para especificar un grupo de Google.

  Los Controles del servicio de VPC solo admiten las identidades v1 que comienzan con los prefijos user, serviceAccount, group (versión preliminar), principal (versión preliminar) y principalSet (versión preliminar) en los identificadores de principal de la API de v1 de IAM.

• sources: (obligatorio): Este atributo hace referencia a una lista de orígenes de red. Cada valor de la lista puede ser un nivel de acceso o un proyecto de Google Cloud. Si estableces el atributo accessLevel como "*", la política de entrada permite el acceso desde cualquier origen de red. Si configuras este atributo en un proyecto de Google Cloud, la política de entrada permite el acceso desde una red de VPC que pertenece al proyecto.

  Es posible que este valor se quite cuando se borre de forma permanente el proyecto asociado. Sin embargo, la eliminación de este valor no genera un error. Siempre verifica si este valor existe mientras solucionas cualquier problema.

• - resource:: (Usa este atributo o el atributo accessLevel) Especifica un proyecto o una red de VPC desde fuera del perímetro al que deseas proporcionar acceso. Para especificar un proyecto, usa el siguiente formato: projects/PROJECT_NUMBER. Para especificar una red de VPC, usa el siguiente formato: //compute.googleapis.com/projects/PROJECT_ID/global/networks/NETWORK_NAME.

• - accessLevel:: (Debe usarse este atributo o el atributo resource) Especifica el nivel de acceso desde fuera del perímetro al que se da acceso. Si estableces el atributo accessLevel como "*", la política de entrada permite el acceso desde cualquier origen de red.

• ingressTo:: Inicia el bloque to, que enumera las operaciones de servicio permitidas en los recursos de Google Cloud especificados en el perímetro (obligatorio).

• operations:: Marca el comienzo de la lista de servicios y las acciones o los métodos accesibles a los que el cliente satisface las condiciones del bloque from a los que puede acceder (obligatorio).

• - serviceName:: Este campo puede ser un nombre de servicio válido o estar configurado como "*" para permitir el acceso a todos los servicios (obligatorio). Por ejemplo, bigquery.googleapis.com es un serviceName válido. Para obtener una lista de los servicios disponibles, consulta Productos compatibles.

• methodSelectors:: Es el comienzo de una lista de métodos a los que un cliente que cumple con las condiciones de bloqueo from puede acceder (obligatorio si serviceName no es "*"). Para obtener una lista de los métodos y permisos restringidos para los servicios, consulta las restricciones de los métodos de servicio compatibles.

• - method:: (Se debe usar este atributo o el atributo permission) Este campo puede ser un método de servicio válido, o puede establecerse como "*" para permitir el acceso a todos los métodos del servicio especificado.

• - permission:: (Se debe usar este atributo o el atributo method) Este campo debe ser un permiso de servicio válido. El acceso a los recursos dentro del perímetro se permite para las operaciones que requieren el permiso.

  Cuando una solicitud a un recurso requiere varios permisos, debes especificar todos los permisos necesarios en la misma operación para que funcione la regla de entrada. Por ejemplo, si una solicitud a un recurso de BigQuery requiere los permisos bigquery.jobs.create y bigquery.tables.create, debes especificar ambos permisos en la misma operación. Además, si especificas los permisos varias veces para el mismo recurso con la consola de Google Cloud, los permisos no se crean en la misma operación. Para evitar este problema, especifica todos los permisos a la vez para el recurso.

• resources: (obligatorio): Este atributo especifica la lista de recursos de Google Cloud en el perímetro de servicio al que puede acceder el cliente fuera del perímetro. Este campo se puede configurar en "*" para permitir el acceso de entrada a cualquier recurso de Google Cloud dentro del perímetro.

Para crear una regla de entrada funcional, debes especificar los siguientes atributos:

• Atributo sources. Debes especificar un accessLevel o un resource (proyecto de Google Cloud o red de VPC) o configurar el atributo accessLevel como "*".

Nota: Para permitir la entrada a recursos, los Controles del servicio de VPC evalúan los atributos sources y identityType como una condición AND, y evalúan los atributos accessLevel y resource del atributo sources como una condición O. Cuando un accessLevel o resource de una fuente se configura en un valor específico en lugar de "*", los Controles del servicio de VPC evalúan los atributos sources y identityType.

• Atributo identityType o identities
• Atributo resources
• Atributo serviceName

Una vez que hayas terminado de configurar tu archivo de políticas de entrada, consulta Actualiza las políticas de entrada y salida para obtener instrucciones sobre cómo aplicarlo a tu perímetro de servicio.

Si configuras varias reglas de entrada en un perímetro de servicio, los Controles del servicio de VPC permiten una solicitud si satisface las condiciones de cualquiera de las reglas de entrada.

Referencia de las reglas de salida

Las reglas de salida se pueden configurar con la consola de Google Cloud, un archivo JSON o un archivo YAML. En el siguiente ejemplo, se usa el formato .yaml:

- egressTo:
    operations:
    - serviceName: SERVICE_NAME
      methodSelectors:
      - method: METHOD
      *OR*
      - permission: PERMISSION
    resources:
    - projects/PROJECT
    *OR*
    externalResources:
    - EXTERNAL_RESOURCE_PATH
  egressFrom:
    identityType: ANY_IDENTITY | ANY_USER_ACCOUNT | ANY_SERVICE_ACCOUNT
    *OR*
    identities:
    - PRINCIPAL_IDENTIFIER

• - egressTo:: Inicia el bloque to, que enumera las operaciones de servicio permitidas en los recursos de Google Cloud en proyectos especificados fuera del perímetro (obligatorio).

• operations:: Marca el comienzo de la lista de servicios y las acciones o los métodos accesibles a los que el cliente satisface las condiciones del bloque from a los que puede acceder (obligatorio).

• - serviceName:: Este campo puede ser un nombre de servicio válido o estar configurado como "*" para permitir el acceso a todos los servicios (obligatorio). Para obtener una lista de los servicios disponibles, consulta Productos compatibles.

• methodSelectors:: Es el comienzo de una lista de métodos a los que un cliente que cumple con las condiciones de bloqueo from puede acceder (obligatorio si serviceName no es "*"). Para obtener una lista de los métodos y permisos restringidos para los servicios, consulta las restricciones de los métodos de servicio compatibles.

• - method:: (Se debe usar este atributo o permission). Este campo puede ser un método de servicio válido o se puede configurar en "*" para permitir el acceso a todos los métodos del servicio especificado.

• - permission:: (Se debe usar este atributo o method). Este campo debe ser un permiso de servicio válido. Se permitirá el acceso a los recursos especificados fuera del perímetro para las operaciones que requieren este permiso.

  Cuando una solicitud a un recurso requiere varios permisos, debes especificar todos los permisos necesarios en la misma operación para que funcione la regla de salida. Por ejemplo, si una solicitud a un recurso de BigQuery requiere los permisos bigquery.jobs.create y bigquery.tables.create, debes especificar ambos permisos en la misma operación. Además, si especificas los permisos varias veces para el mismo recurso con la consola de Google Cloud, los permisos no se crean en la misma operación. Para evitar este problema, especifica todos los permisos a la vez para el recurso.

• resources:: Este atributo es una lista de recursos de Google Cloud especificados por sus proyectos a los que los clientes dentro de un perímetro pueden acceder. Puedes configurar este campo en "*" para permitir el acceso de salida a cualquier recurso de Google Cloud.

• externalResources:: Este atributo solo se usa para especificar recursos de BigQuery Omni. Este atributo es una lista de recursos externos compatibles con BigQuery Omni a los que pueden acceder los clientes dentro de un perímetro. Solo puedes especificar recursos de Amazon S3 o Azure Blob Storage. Para Amazon S3, el formato admitido es s3://BUCKET_NAME. Para Azure Storage, el formato admitido es azure://myaccount.blob.core.windows.net/CONTAINER_NAME.

• egressFrom:: Inicia el bloque from que enumera las identidades y las fuentes permitidas dentro del perímetro (obligatorio).

• identityType:: (Se debe usar este atributo o identities). Este atributo define los tipos de identidades que se pueden usar para acceder a los recursos especificados fuera del perímetro. Valores aceptables: ANY_IDENTITY, ANY_USER_ACCOUNT, ANY_SERVICE_ACCOUNT. ANY_IDENTITY permite todas las identidades. ANY_USER_ACCOUNT permite a todos los usuarios humanos. ANY_SERVICE_ACCOUNT permite todas las cuentas de servicio.

  Este atributo no restringe las identidades en función de la organización. Por ejemplo, ANY_SERVICE_ACCOUNT permite una cuenta de servicio de cualquier organización.

• identities:: (Se debe usar este atributo o identityType). Este atributo inicia una lista de cuentas de servicio, cuentas de usuario, grupos de Google o identidades de terceros que pueden acceder a los recursos especificados fuera del perímetro.

• PRINCIPAL_IDENTIFIER: Especifica una cuenta de usuario, una cuenta de servicio, un grupo de Google o una identidad de terceros que pueda acceder a los recursos especificados fuera del perímetro. Usa el formato especificado en Identificadores principales de la API de v1 IAM. Por ejemplo, usa el formato group:[e-mail] para especificar un grupo de Google.

  Los Controles del servicio de VPC solo admiten las identidades v1 que comienzan con los prefijos user, serviceAccount, group (versión preliminar), principal (versión preliminar) y principalSet (versión preliminar) en los identificadores de principal de la API de v1 de IAM.

Una vez que hayas terminado de configurar tu archivo de políticas de salida, consulta Actualiza las políticas de entrada y salida para obtener instrucciones sobre cómo aplicarlo a tu perímetro de servicio.

Si configuras varias reglas de salida en un perímetro de servicio, los Controles del servicio de VPC permiten una solicitud si satisface las condiciones de cualquiera de las reglas de salida.

Usa el modo de ejecución de prueba para probar políticas de entrada y salida

Cuando no quieres otorgar acceso a todos los métodos de un servicio, a veces puede ser difícil determinar la lista precisa de métodos que se permitirán. Esto puede ocurrir porque un método determinado para un servicio puede hacer que se invoque un método diferente en un servicio de Google Cloud separado. Por ejemplo, BigQuery carga una tabla desde un bucket de Cloud Storage para ejecutar una consulta.

Para determinar el conjunto correcto de métodos que se permitirán, puedes usar el modo de ejecución de prueba de los Controles del servicio de VPC. Para ello, primero habilita un perímetro en el modo de ejecución de prueba sin políticas de entrada o salida y recopila la lista de métodos invocados desde el registro de auditoría. Luego, agrega estos métodos de forma progresiva a las políticas de entrada y salida en el modo de ejecución de prueba hasta que se detengan todas las infracciones. En ese punto, la configuración se puede cambiar del modo de ejecución de prueba al modo de aplicación forzosa.

Características no compatibles

Actualmente, las siguientes funciones no se aplican a las reglas de entrada y salida:

1. Identificar los recursos de Google Cloud por etiquetas y no por proyectos.
2. No todos los servicios admiten reglas de entrada o salida por método. Consulta Restricciones de los métodos de servicio compatibles.
3. Los tipos de identidad ANY_SERVICE_ACCOUNT y ANY_USER_ACCOUNT no se pueden usar para permitir las siguientes operaciones:
   • Todas las operaciones de Container Registry
   • Todas las operaciones del servicio notebooks.googleapis.com
   • Operaciones de Cloud Storage mediante URL firmadas
   • Con las funciones de Cloud Run, la implementación de una Cloud Function desde la máquina local
   • Exporta registros de un receptor de Cloud Logging a un recurso de Cloud Storage.
   • Todas las operaciones de la interfaz de usuario web de Apache Airflow en Cloud Composer

Limitaciones

Para obtener información sobre los límites de entrada y salida, consulta Cuotas y límites.

¿Qué sigue?

• Completa este codelab para aprender a corregir los incumplimientos de entrada y salida.