En esta guía se describe cómo extender las políticas de acceso de Identity-Aware Proxy (IAP) mediante niveles de acceso y el framework de las Condiciones de la administración de identidades y accesos (IAM). Los niveles de acceso permiten configurar restricciones para acceder a los recursos según las direcciones IP y los atributos del dispositivo del usuario final. Las condiciones de IAM permiten restringir el acceso según las rutas de acceso y los hosts de URL, así como la fecha y hora.
Por ejemplo, según la configuración de la política, tu aplicación sensible puede realizar estas acciones:
- Otorgar acceso a todos los empleados si usan un dispositivo corporativo de confianza de tu red corporativa
- Otorgar acceso a los empleados que estén en el grupo Acceso remoto si utilizan un dispositivo empresarial de confianza con una contraseña segura y un parche actualizado desde cualquier red
- Otorgar acceso solo a los empleados del grupo Acceso privilegiado si la ruta de URL comienza con
/admin
Antes de comenzar
Necesitarás lo siguiente antes de comenzar:
- Una aplicación protegida con IAP a la que deseas agregar acceso individual o grupal
- Nombres de usuarios o grupos a los que deseas otorgar acceso
Configura los niveles de acceso
Deberás crear un nivel de acceso, para limitar el acceso por dirección IP o por atributos del dispositivo del usuario final. Si deseas saber cómo crear un nivel de acceso, consulta la guía de Access Context Manager. IAP usa el nombre del nivel de acceso para asociarlo con una aplicación protegida con IAP.
IAP no admite el uso de políticas con alcance. Los niveles de acceso se deben establecer en la política de acceso de la organización. Para obtener más información, consulta Crea una política de acceso.
Edita la política de IAM
Una aplicación protegida con IAP tiene una política de IAM que vincula la función IAP a la aplicación.
Cuando se agrega una vinculación condicional de IAM a la política de IAM, el acceso a tus recursos está más restringido según atributos de solicitud. Estos incluyen lo siguiente:
- Niveles de acceso
- Ruta de acceso/host de URL
- Fecha/hora
Ten en cuenta que deben ser exactos los valores de solicitud que se comparen con request.host
y request.path
especificados en una vinculación condicional de IAM. Por ejemplo, si restringes el acceso a rutas de acceso que empiezan con /internal admin
, es posible evitar la restricción si se accede a /internal%20admin
. Para obtener más información sobre las condiciones de los nombres de host y las rutas de acceso, consulta cómo usar las condiciones de ruta de acceso y nombre de host.
Agrega y edita vinculaciones condicionales en tu política de IAM mediante el proceso que se describe a continuación.
Console
Para agregar una vinculación condicional con la consola de Google Cloud, sigue estos pasos:
Ve a la página de administrador de IAP.
Selecciona la casilla de verificación junto a los recursos para los que deseas actualizar los permisos de IAM.
En el panel de información a la derecha, haz clic en Agregar principal.
En el cuadro Principal nueva, ingresa las principales a las que deseas asignarles un rol.
En la lista desplegable Seleccionar un rol, selecciona el rol Usuario de app web protegida con IAP y especifica las condiciones de nivel de acceso que deberán cumplir las principales para acceder al recurso.
- Para especificar los niveles de acceso existentes, selecciónalos en la lista desplegable Niveles de acceso. Debes seleccionar la función Usuario de aplicación web protegida con IAP y tener permisos de nivel de organización para ver los niveles de acceso existentes. Se te deben otorgar algunas de las siguientes funciones:
- Administrador de Access Context Manager
- Editor de Access Context Manager
- Lector de Access Context Manager
- Para crear y administrar los niveles de acceso, usa Access Context Manager.
- Para especificar los niveles de acceso existentes, selecciónalos en la lista desplegable Niveles de acceso. Debes seleccionar la función Usuario de aplicación web protegida con IAP y tener permisos de nivel de organización para ver los niveles de acceso existentes. Se te deben otorgar algunas de las siguientes funciones:
Si deseas agregar más roles a las principales, haz clic en Agregar otro rol.
Cuando hayas agregado todas las funciones que necesitas, haz clic en Guardar.
Acabas de agregar una vinculación condicional a tu recurso.
Para quitarla, sigue estos pasos:
Ve a la página de administrador de IAP.
Selecciona la casilla de verificación junto al recurso del que quieres quitar el rol de IAM de una principal.
En el panel de información de la derecha, en Función/Director, haz clic en la función que deseas quitarle al director.
Haz clic en Quitar junto a la principal.
En el diálogo Quitar rol de la principal que aparece, haz clic en Quitar. Para quitar todos los roles no heredados de la principal en el recurso seleccionado, selecciona la casilla de verificación antes de hacer clic en Quitar.
gcloud
Por ahora, solo puedes usar la herramienta gcloud para establecer vinculaciones condicionales a nivel de proyecto.
Para establecer vinculaciones condicionales, edita el archivo policy.yaml
de tu proyecto mediante el siguiente proceso:
Abre la política de IAM de la aplicación con el siguiente comando de gcloud:
gcloud iap web get-iam-policy --project=PROJECT_ID > policy.yaml
Edita el archivo
policy.yaml
para especificar lo siguiente:- Los usuarios y los grupos a los que deseas aplicar la condición de IAM
- La función
iap.httpsResourceAccessor
para otorgarles acceso a los recursos La condición de IAM.
En el siguiente fragmento, se muestra una condición de IAM con solo un atributo especificado. Esta condición otorga acceso al usuario y al grupo si se cumple con los requisitos de nivel de acceso ACCESS_LEVEL_NAME y la ruta de la URL del recurso comienza con
/
.
bindings: ... - members: - group:EXAMPLE_GROUP@GOOGLE.COM - user:EXAMPLE_USER@GOOGLE.COM role: roles/iap.httpsResourceAccessor condition: expression: "accessPolicies/ORGANIZATION_NUMBER/accessLevels/ACCESS_LEVEL_NAME" in request.auth.access_levels && request.path.startsWith("/") title: CONDITION_TITLE ...
Vincula la política a la aplicación con el comando
set-iam-policy
.gcloud iap web set-iam-policy --project=PROJECT_ID policy.yaml
Tu política de IAM ahora incluye una vinculación condicional.
API
A fin de editar el archivo policy.json
de tu aplicación, sigue el proceso que se muestra a continuación para tu tipo de aplicación.
Consulta Administra el acceso a los recursos protegidos por IAP a fin de obtener más información sobre cómo usar la API de IAM para administrar las políticas de acceso.
Antes de seguir los pasos específicos de la aplicación de la API que se indican a continuación, exporta lo siguiente: variables:
export PROJECT_NUM=PROJECT_NUMBER export IAP_BASE_URL=https://iap.googleapis.com/v1/projects/${PROJECT_NUM}/iap_web # Replace POLICY_FILE.JSON with the name of JSON file to use for setIamPolicy export JSON_NEW_POLICY=POLICY_FILE.JSON
App Engine
Exporta las siguientes variables de App Engine:
# The APP_ID is usually the project ID export GAE_APP_ID=APP_ID export GAE_BASE_URL=${IAP_BASE_URL}/appengine-${GAE_APP_ID}
Obtén la política de IAM para la aplicación de App Engine con el método
getIamPolicy
. El bit de datos vacío al final convierte la solicitudcurl
en POST en lugar de GET.curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \ ${GAE_BASE_URL}/:getIamPolicy -d ''
Agrega tu vinculación condicional de IAM al archivo JSON de la política de IAM. A continuación, se muestra un ejemplo de un archivo
policy.json
editado que vincula la funcióniap.httpsResourceAccessor
a dos usuarios y les otorga acceso a los recursos protegidos con IAP. Se agregó una condición de IAM para otorgarles acceso a los recursos solo si se cumple el requisito de nivel de acceso ACCESS_LEVEL_NAME y la ruta de URL del recurso comienza con/
. Solo puede haber una condición por vinculación.
Archivo policy.json de ejemplo{ "policy": { "bindings": [ { "role": "roles/iap.httpsResourceAccessor", "members": [ "group:EXAMPLE_GROUP@GOOGLE.COM", "user:EXAMPLE_USER@GOOGLE.COM" ], "condition": { "expression": ""accessPolicies/ORGANIZATION_NUMBER/accessLevels/ACCESS_LEVEL_NAME" in request.auth.access_levels && request.path.startsWith("/")", "title": "CONDITION_NAME" } } ] } }
Configura tu nuevo archivo
policy.json
con el métodosetIamPolicy
.curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \ ${GAE_BASE_URL}:setIamPolicy -d @${JSON_NEW_POLICY}
Servicios y versiones de App Engine
También puedes actualizar la política de IAM para un servicio de App Engine, todas las versiones o una versión específica de un servicio. Sigue estos pasos para hacerlo con una versión específica de un servicio:
- Exporta las siguientes variantes adicionales.
export GAE_SERVICE=SERVICE_NAME export GAE_VERSION=VERSION_NAME
- Actualiza la variante GAE_BASE_URL exportada.
export GAE_BASE_URL=${IAP_BASE_URL}/appengine-${GAE_APP_ID}/services/${GAE_SERVICE}/versions/${GAE_VERSION}
- Obtén y establece la política de IAM para la versión con los comandos
getIamPolicy
ysetIamPolicy
que se muestran arriba.
GKE y Compute Engine
Exporta el ID del proyecto de tu servicio de backend.
export BACKEND_SERVICE_NAME=BACKEND_SERVICE_NAME
Obtén la política de IAM para la aplicación de Compute Engine con el método
getIamPolicy
. El bit de datos vacío al final convierte la solicitudcurl
en POST en lugar de GET.curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \ ${IAP_BASE_URL}/compute/services/${BACKEND_SERVICE_NAME}:getIamPolicy \ -d ''
Agrega tu vinculación condicional de IAM al archivo JSON de la política de IAM. A continuación, se muestra un ejemplo de un archivo
policy.json
editado que vincula la funcióniap.httpsResourceAccessor
a dos usuarios y les otorga acceso a los recursos protegidos con IAP. Se agregó una condición de IAM para otorgarles acceso a los recursos solo si se cumple el requisito de nivel de acceso ACCESS_LEVEL_NAME y la ruta de URL del recurso comienza con/
. Solo puede haber una condición por vinculación.
Archivo policy.json de ejemplo{ "policy": { "bindings": [ { "role": "roles/iap.httpsResourceAccessor", "members": [ "group":EXAMPLE_GROUP@GOOGLE.COM, "user:EXAMPLE_USER@GOOGLE.COM" ], "condition": { "expression": ""accessPolicies/ORGANIZATION_NUMBER/accessLevels/ACCESS_LEVEL_NAME" in request.auth.access_levels && request.path.startsWith("/")", "title": "CONDITION_NAME" } } ] } }
Configura tu nuevo archivo
policy.json
con el métodosetIamPolicy
.curl -i -H "Content-Type:application/json" \ -H "Authentication: Bearer $(gcloud auth print-access-token)" \ ${IAP_BASE_URL}/compute/services/${BACKEND_SERVICE_NAME}:setIamPolicy \ -d @${JSON_NEW_POLICY}
Utiliza las condiciones del nombre de host y la ruta de acceso
El acceso a tu aplicación se puede proteger con el nombre de host y la ruta de acceso de una URL de solicitud.
Por ejemplo, la condición request.path.startsWith
de IAM se puede usar para otorgar acceso únicamente a los empleados del grupo de Acceso privilegiado si la ruta de URL comienza con /admin
.
Para obtener más información sobre cómo usar las condiciones de nombre de host y ruta de acceso, consulta los atributos de solicitud.
Normalización de strings
Una URL tiene un nombre de host y una ruta de acceso. Por ejemplo, la URL https://sheets.google.com/create?query=param
tiene como nombre de host sheets.google.com
y como ruta de acceso /create
.
Los backends pueden interpretar nombres de host y rutas de acceso de diferentes maneras. Para evitar la ambigüedad, IAP normaliza las strings de ruta de acceso y nombre de host mediante la comprobación de las políticas.
IAP realiza dos verificaciones de la política cuando una solicitud tiene una ruta de acceso no normalizada. Si la ruta no normalizada supera la verificación de la política, IAP normaliza la ruta de acceso y se realiza una segunda verificación de la política. El acceso se otorga si las rutas normalizadas y no normalizadas pasan la verificación de la política.
Por ejemplo, si una solicitud tiene la ruta de acceso /internal;some_param/admin
, IAP primero realiza una verificación de política en la ruta no normalizada (/internal
). Si eso sucede, IAP realiza una segunda verificación de la política en la ruta normalizada (/internal/admin
).
Nombres de host
Los nombres de host se normalizan de la siguiente manera:
- Eliminación de puntos finales
- Caracteres en minúscula
- Conversión a ASCII
Los nombres de host que incluyen caracteres que no son ASCII tienen una normalización adicional con punycoding. Debes usar punycode en la string de nombre de host para que se realice una coincidencia.
Para usar punycode en tu string de nombre de host, usa un conversor, como Punycoder.
Los siguientes son ejemplos de nombres de host normalizados:
FOO.com
se normaliza enfoo.com
café.fr
se normaliza enxn--caf-dma.fr
Rutas de acceso
Las rutas se normalizan de la siguiente manera:
- Eliminación de parámetros de ruta de acceso
- Resolución de rutas relativas a su equivalente absoluto
Un parámetro de ruta de acceso incluye todos los caracteres desde un ;
hasta el siguiente /
o el final de la ruta.
Las solicitudes que contienen ..;
al comienzo de una sección de ruta se consideran no válidas.
Por ejemplo, /..;bar/
y /bar/..;/
muestran el error HTTP 400: Bad Request
.
Los siguientes son ejemplos de rutas de acceso normalizadas:
/internal;some_param/admin
se normaliza en/internal/admin
/a/../b
se normaliza en/b
/bar;param1/baz;baz;param2
se normaliza en/bar/baz
Terminaciones de subdominios
Una política establecida con request.host.endsWith("google.com")
coincidirá tanto con sub_domain.google.com
como con testgoogle.com
. Si tu objetivo es limitar tu política a todos los subdominios que terminan con google.com
, establece la política en request.host.endsWith(".google.com")
.
Ten en cuenta que cuando configuras tu política en request.host.endsWith(".google.com")
coincidirá con sub_domain.google.com
, pero no coincidirá con google.com
debido a .
adicional.
Cloud Audit Logging y niveles de acceso
La habilitación de Cloud Audit Logging para tu proyecto protegido con IAP te permite ver solicitudes de acceso autorizadas y no autorizadas. Sigue los pasos que aparecen a continuación para ver las solicitudes y todos los niveles de acceso con que cumple un solicitante:
-
Ve a la consola de Google Cloud
Explorador de registros del proyecto.
Ir a la página Registros - En la lista desplegable del selector de recursos, selecciona un recurso. Los recursos de HTTPS protegidos con IAP se encuentran en la Aplicación de GAE y el Servicio de backend de GCE. Los recursos de SSH y TCP protegidos con IAP se encuentran en la instancia de VM en GCE.
- En la lista desplegable tipo de registros, selecciona data_access.
- El tipo de registro data_access solo aparece si se registró tráfico hacia tu recurso después de habilitar Cloud Audit Logging para IAP.
- Haz clic para ampliar la fecha y la hora del acceso que deseas revisar.
- El acceso autorizado tiene un ícono
i
de color azul. - El acceso no autorizado tiene un ícono
!!
de color naranja.
- El acceso autorizado tiene un ícono
- A fin de ver los niveles de acceso que obtuvo el solicitante, haz clic para expandir las secciones hasta llegar a
protoPayload
>requestMetadata
>requestAttributes
>auth
>accessLevels
.
Ten en cuenta que todos los niveles de acceso con los que cumple un usuario son visibles cuando se ve una solicitud, incluidos los niveles de acceso que no se solicitaron para acceder a ella. Ver una solicitud no autorizada no indica cuáles son los niveles de acceso con los no se cumplieron. Esto último se determina mediante la comparación de las condiciones del recurso con los niveles de acceso visibles en la solicitud.
Consulta la guía de Cloud Audit Logging para obtener más información sobre los registros.