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

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

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.
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.
Minimiza el riesgo de robo de datos mediante la restricción del servicio, los métodos, los proyectos de Google Cloud, las redes de VPC y las identidades exactos que se usan para ejecutar el intercambio de datos.
Otorga acceso de solo lectura a las imágenes y conjuntos de datos externos que no administras.
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.
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 los 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.

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 gsutil 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 que está 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 gsutil cp).

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

En los ejemplos de BigQuery y Compute Engine, no hay suficiente regla de entrada, ya que el trabajo de BigQuery o el disco de Compute Engine están fuera del perímetro. Se necesita 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 de Cloud Storage y un bucket 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 b de Cloud Storage
Una regla de salida en el perímetro B para permitir el acceso al bucket a de Cloud Storage
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 mediante la consola de Google Cloud, un archivo JSON o YAML. En el siguiente ejemplo, se usa el formato .yaml:

- ingressFrom:
    identityType: ANY_IDENTITY | ANY_USER_ACCOUNT | ANY_SERVICE_ACCOUNT
    *OR*
    identities:
    - serviceAccount:service-account
    - user:user-account
    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.
identities:: Se debe usar este atributo o el atributo identityType. Este atributo inicia una lista de cuentas de servicio o de usuario que pueden acceder a los recursos en el perímetro. No se admite la entrada por identidades de federación de identidades de cargas de trabajo.
serviceAccount: Una cuenta de servicio a la que se le otorga acceso a los recursos en el perímetro.
user: Es una cuenta de usuario a la que se otorga acceso a los recursos en el perímetro.
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 estableces 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.
- 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: (obligatorio si serviceName no es \"*\"): Es el comienzo de una lista de métodos a los que un cliente que cumple con las condiciones de bloqueo de from puede acceder. A fin de obtener una lista de métodos y permisos para restringir para servicios, consulta 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 en la misma operación. Además, si especificas los permisos varias veces para el mismo recurso mediante la consola de Google Cloud, los permisos no se crean con la misma operación. A fin de 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 establecer el atributo accessLevel en \"*\".

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.

Referencia de las reglas de salida

Las reglas de salida se pueden configurar mediante la consola de Google Cloud, un archivo JSON o 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:
    - serviceAccount:service-account
    - user:user-account

- 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: (obligatorio si serviceName no es \"*\"): Es el comienzo de una lista de métodos a los que un cliente que cumple con las condiciones de bloqueo de from puede acceder. A fin de obtener una lista de métodos y permisos para restringir para servicios, consulta 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 bajo 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 en la misma operación. Además, si especificas los permisos varias veces para el mismo recurso mediante la consola de Google Cloud, los permisos no se crean con la misma operación. A fin de evitar este problema, especifica todos los permisos a la vez para el recurso.
resources:: Este atributo es una lista de recursos de Google Cloud que especifican sus proyectos a los que pueden acceder los clientes dentro de un perímetro. Puedes configurar este campo como \"*\" 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 compatible 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.
identities:: (Se debe usar este atributo o identityType). Este atributo inicia una lista de cuentas de servicio o de usuario que pueden acceder a los recursos especificados fuera del perímetro. No se admite la salida por identidades de federación de identidades para cargas de trabajo.
serviceAccount: Una cuenta de servicio que puede acceder a los recursos especificados fuera del perímetro.
user: Es una cuenta de usuario que puede acceder a los recursos especificados fuera del perímetro.

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.

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:

Identificar los recursos de Google Cloud por etiquetas y no por proyectos.
Especificar grupos en el campo identities de una regla from de entrada o salida.
No todos los servicios admiten reglas de entrada o salida por método. Consulta Restricciones de los métodos de servicio compatibles.
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 de servicio de notebooks.googleapis.com.
- Operaciones de Cloud Storage mediante URL firmadas
- Con Cloud Functions, 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.

Limitaciones

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