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 recursos y clientes protegidos por 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 un ejemplo de caso de uso, consulta Ejemplo de uso de grupos de identidad y las identidades de terceros en los entornos de entrada y salida reglas.

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. Limita el servicio, los métodos y la seguridad para minimizar el riesgo de robo de datos. Proyectos de Google Cloud, identidades y redes de VPC 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 se invoca en el recurso. Así, las definiciones hacen referencia a la dirección de la 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 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).
  • 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 una instancia de Compute Engine fuera del perímetro con una clave de Cloud KMS perímetro de servicio.

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

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 la Cliente de Cloud Storage para copiar 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 Cloud Storage bucket b ,
  • una regla de salida en el perímetro B para permitir el acceso al Cloud Storage bucket a,
  • una regla de entrada en el perímetro B para permitir el acceso 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.

  • 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 cuentas las identidades que pueden acceder a recursos en el 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 quieres proporcionar acceso recursos en el perímetro. Usa el formato especificado en Identificadores principales de la API de v1 IAM. Por ejemplo, usa el group:GROUP_NAME@googlegroups.com 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) y principal (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 como un proyecto de Google Cloud, el la política de entrada permite acceder 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 causa un error. Verificar siempre que este valor exista 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: (obligatorio si serviceName no es "*") al comienzo de una lista de métodos a los que un cliente que satisface las condiciones de bloque from tienen permitido el acceso. Para obtener una lista de métodos y permisos restrictivos para servicios, consulta Restricciones de métodos de servicio admitidos.

  • - 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 la regla de entrada el trabajo. 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 el la consola de Google Cloud, los permisos no se crean con 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 establece 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 con 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:
    - 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: (obligatorio si serviceName no es "*") al comienzo de una lista de métodos a los que un cliente que satisface las condiciones de bloque from tienen permitido el acceso. Para obtener una lista de métodos y permisos restrictivos para servicios, consulta Restricciones de métodos de servicio admitidos.

  • - 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 la regla de salida el trabajo. 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 el la consola de Google Cloud, los permisos no se crean con 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 Google Cloud de recursos especificados por sus proyectos que los clientes dentro de un perímetro el acceso a los datos. 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 las que pueden acceder los clientes dentro de un perímetro. Puedes especificar solo Amazon S3 Recursos de Azure Blob Storage. Para Amazon S3, el formato admitido es s3://BUCKET_NAME. Para Azure Storage, el formato compatible 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). Esta inicia una lista de cuentas de servicio, cuentas de usuario, Grupos de Google o las 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 v1 de IAM Identificadores de la principal de la API. Por ejemplo, usa el formato group:GROUP_NAME@googlegroups.com para especificar un grupo de Google.

    Los Controles del servicio de VPC solo admiten las identidades v1 que comienzan con el user, serviceAccount, group (vista previa), y principal (Preview) en la carpeta de IAM v1 Identificadores de la principal de la API.

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:

  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:

Limitaciones

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