Protege tu Cloud Function

En esta página, se proporciona una descripción general de alto nivel de las formas en las que puedes controlar las interacciones con tus recursos de Cloud Functions.

Control de acceso

Existen dos enfoques para controlar el acceso a Cloud Functions:

• Basado en la identidad
• Basado en la red

Protege el acceso con identidad

Una forma de controlar el acceso a una función es requerir que la entidad solicitante se identifique mediante una credencial. Una credencial es un “nombre” de algún tipo, protegido por un Secret al que la entidad conoce o tiene acceso, como una contraseña o una llave de hardware. Según la configuración predeterminada, las funciones se implementan como privadas y requieren esa credencial, aunque es posible implementar una función como pública, es decir, no requiere credenciales.

El primer paso del proceso es validar la credencial para asegurarse de que el solicitante sea quien dice ser y que presente el nombre y la combinación secreta correctos. Este paso se llama (Authentication).

Una vez que se autentica la identidad del solicitante, se puede evaluar su nivel de acceso, es decir, los permisos que se le otorgaron a la identidad. Este paso se llama (Authorization).

Autenticación

Cloud Functions admite dos tipos diferentes de identidades, que también se llaman principales:

• Cuentas de servicio: Estas son cuentas especiales que actúan como la identidad de una entidad que no es una persona, como una función, una aplicación o una VM. Te brindan una forma de autenticar a las entidades que no son personas.
• Cuentas de usuario: Estas cuentas representan personas, ya sea como titulares de cuentas de Google individuales o como parte de una entidad controlada por Google, como un Grupo de Google.

Tanto para las cuentas de servicio como para las cuentas de usuario, la parte del nombre de la credencial suele ser una dirección de correo electrónico asociada con la cuenta. Por lo general, el Secret de una cuenta de usuario es una contraseña y, el de una cuenta de servicio suele ser la clave privada del par de claves que se crea junto con la cuenta.

Sin embargo, las contraseñas de usuarios y las claves de las cuentas de servicio son muy potentes, ya que pueden proporcionar acceso amplio a los datos y la funcionalidad, y permanecen vigentes hasta que se revocan o cambian de forma activa. Por lo tanto, para limitar el posible daño que podría ocurrir si se filtra la credencial, en Google Cloud, esta credencial principal se reemplaza por una credencial a corto plazo basada en ella, un token, uno que tiene una vida útil limitada y se crea en el momento como parte de la secuencia de solicitud. El token se pasa con la solicitud y se usa para autenticar la cuenta de forma segura.

Existen dos tipos de tokens que se usan en Cloud Functions: tokens de acceso y tokens de ID. Por lo general, los tokens de acceso se usan para autenticar las llamadas a la API, y los tokens de ID se usan para autenticar las llamadas al código creado por el desarrollador, por ejemplo, si una función llama a otra función. Los tokens se crean mediante el framework de OAuth 2 y su extensión, Open Identity Connect, pero la secuencia es compleja y propensa a errores, y se recomienda el uso de las bibliotecas cliente de Cloud para administrar el proceso.

Autorización

Una vez que se confirme la identidad de la entidad solicitante, se debe evaluar lo que el solicitante tiene permitido hacer. Esta evaluación se basa en los permisos que se le otorgaron a la cuenta autenticada cuando se configuró. Cloud Functions usa la Identity and Access Management (IAM) para hacer esto. Los roles, que son conjuntos de permisos individuales agrupados para mayor comodidad, se asignan a la cuenta directamente o mediante una configuración llamada política. Cada permiso individual del conjunto de roles suele corresponder a una sola llamada a la API de REST que el servicio solicitado expone. Para obtener más información sobre este proceso, consulta Autoriza el acceso a través de IAM.

Control de acceso basado en la red

También puedes limitar el acceso si especificas la configuración de red para funciones individuales. Esto permite un control preciso sobre la entrada y salida de la red hacia y desde tus funciones.

Aislamiento y zona de pruebas

De forma interna, las instancias de función están aisladas entre sí mediante la plataforma de zona de pruebas gVisor. Por diseño, una función no puede acceder a los entornos operativos de otras funciones.