En esta página se describen las políticas de la organización de AlloyDB para PostgreSQL, que los administradores de la organización usan para establecer restricciones sobre cómo configuran los usuarios los clústeres y las copias de seguridad de esa organización.
Los proyectos, las carpetas y las organizaciones son recursos de contenedor organizados en una jerarquía de recursos de elemento superior y elemento secundario. Una organización es el nodo raíz de esa jerarquía. Para obtener más información, consulta Jerarquía de recursos.
Las políticas de organización contienen reglas, llamadas restricciones, que el administrador de la organización aplica a un proyecto, una carpeta o una organización. Las restricciones aplican una política en todos los clústeres y las copias de seguridad. Por ejemplo, si intentas crear un clúster o una copia de seguridad en una entidad que tiene una política de organización, la restricción realiza una comprobación para asegurarse de que la configuración del clúster o de la copia de seguridad cumple los requisitos de la restricción. Si la comprobación falla, AlloyDB no crea el clúster ni el recurso de copia de seguridad.
Cuando añades proyectos a una organización o carpeta que usa una política de organización, los proyectos heredan las restricciones de esa política.
Para obtener más información sobre las políticas de organización, consulta los artículos Introducción al servicio de políticas de organización, Restricciones y Información sobre la evaluación de la jerarquía.
Las siguientes políticas de la organización son específicas de AlloyDB:
Políticas de organización predefinidas
Para empezar, puedes usar la configuración de claves de cifrado gestionadas por el cliente (CMEK) de los clústeres y las copias de seguridad de AlloyDB. Para obtener más información, consulta Usar políticas de la organización predefinidas. Para tener un control granular y personalizable sobre otros ajustes admitidos, usa restricciones personalizadas. Para obtener más información, consulta Usar políticas de organización personalizadas.
Políticas de organización de claves de cifrado gestionadas por el cliente (CMEK)
AlloyDB admite las siguientes restricciones de política de organización:
constraints/gcp.restrictNonCmekServices
: requiere protección de CMEK para la APIalloydb.googleapis.com
. Cuando añades esta restricción yalloydb.googleapis.com
a la lista de servicios de la políticaDeny
, AlloyDB no crea un clúster ni un recurso de copia de seguridad a menos que el clúster o el recurso de copia de seguridad nuevos tengan habilitadas las CMEK.constraints/gcp.restrictCmekCryptoKeyProjects
: limita las claves criptográficas de Cloud KMS que se pueden usar para la protección con CMEK en clústeres y copias de seguridad de AlloyDB. Cuando AlloyDB crea un clúster o una copia de seguridad con CMEK y esta restricción, la CryptoKey debe proceder de un proyecto, una carpeta o una organización permitidos.
Estas restricciones ayudan a garantizar la protección con CMEK en toda la organización y solo se aplican a los clústeres y las copias de seguridad de AlloyDB que se creen. Para obtener más información, consulta Políticas de organización de CMEK y Restricciones de las políticas de organización.
Políticas de organización personalizadas
Para tener un control granular y personalizable sobre los ajustes, puedes crear restricciones personalizadas y usarlas en una política de organización personalizada. Usa políticas de organización personalizadas para mejorar la seguridad, el cumplimiento y la gobernanza.
Para saber cómo crear políticas de organización personalizadas, consulta el artículo Usar políticas de organización personalizadas. También puedes consultar una lista de restricciones y operaciones personalizadas admitidas.
Reglas de cumplimiento de las políticas de organización
AlloyDB aplica la política de organización en las siguientes operaciones:
- Creación de instancia
- Actualización de la instancia
- Creación de clústeres
- Creación de copias de seguridad
Al igual que todas las restricciones de políticas de la organización, los cambios en las políticas no se aplican de forma retroactiva a los clústeres y las copias de seguridad que ya existen. Estos son algunos ejemplos:
- Una nueva política no tiene ningún efecto en las instancias, los clústeres ni las copias de seguridad que ya existan.
- A menos que un usuario cambie la configuración de la instancia, el clúster o la copia de seguridad de un estado de cumplimiento a un estado de incumplimiento mediante la Google Cloud consola Google Cloud , la CLI de gcloud o RPC, la configuración de la instancia, el clúster o la copia de seguridad seguirá siendo válida.
- Una actualización de mantenimiento programada no provoca la aplicación de la política porque el mantenimiento no cambia la configuración de las instancias, los clústeres ni las copias de seguridad.
Siguientes pasos
- Usar políticas de organización predefinidas.
- Consulta cómo funciona la IP privada con AlloyDB.
- Consulta cómo configurar servicios privados en AlloyDB.
- Consulta información sobre el servicio de políticas de organización.
- Consulta información sobre las restricciones de las políticas de la organización.