Los compartimentos no son carpetas: diseñar una tenancy de OCI que siga siendo manejable

Los equipos que llegan a Oracle Cloud desde AWS buscan la frontera de cuenta, encuentran un compartimento, deciden que es lo mismo y construyen una tenancy con cuarenta compartimentos que copian el organigrama. Seis meses después nadie sabe decir en qué compartimento debe ir un recurso, y las políticas de IAM son un muro de texto.

Un compartimento no es una cuenta. Es un contenedor lógico contra el que se escriben las políticas, y entender esa diferencia es casi todo el diseño.

Qué te da de verdad un compartimento

• Un destino de política. Las políticas de IAM en OCI son frases: allow group Developers to manage instance-family in compartment dev. El compartimento es el sustantivo que le da alcance a la frase.
• Una frontera de cuota. Puedes fijar límites de servicio por compartimento, que es cómo impides que un equipo consuma la cuota de GPU de la tenancy.
• Una dimensión de coste. El análisis de costes agrupa por compartimento, así que el compartimento es tu unidad principal de atribución junto a las etiquetas.
• Una unidad de borrado. Borrar un compartimento borra lo que contiene, lo que es útil y peligroso en las proporciones habituales.

Lo que no te da es una frontera de seguridad dura como la de una cuenta separada de AWS. Todo vive en una tenancy, y una política escrita a nivel de tenancy se aplica en todas partes. La tenancy es el radio de explosión; los compartimentos son cómo te organizas dentro.

La estructura que desplegamos

Plana y por función, no por equipo:

raíz (aquí no vive nada directamente)
├── security          (vaults, logging, configuración de Cloud Guard)
├── network           (VCN, DRG, balanceadores, pasarelas)
├── shared            (registro, CI, bastión)
├── prod
│   ├── carga-a
│   └── carga-b
├── nonprod
│   ├── carga-a
│   └── carga-b
└── sandbox           (por ingeniero, con cuotas y un trabajo de limpieza)

Se admiten seis niveles de anidamiento; dos o tres es lo que deberías usar. Las políticas se heredan hacia abajo, así que allow group NetworkAdmins to manage virtual-network-family in compartment network cubre todo lo de dentro sin enumerar nada.

Mantén vacío el compartimento raíz. Los recursos en la raíz son los que después no se pueden mover con limpieza y a los que toca cada política de nivel tenancy.

Políticas: pocas, heredadas y escritas contra grupos

Tres reglas mantienen legible el IAM de OCI:

Escribe las políticas en el compartimento más alto donde deban aplicarse. Una política por compartimento de carga repetida veinte veces son veinte cosas que cambiar.

Usa grupos dinámicos para principales de instancia y de función. Un grupo dinámico empareja recursos por regla —todas las instancias de un compartimento, todas las funciones con una etiqueta— y te permite escribir allow dynamic-group app-instances to read objects in compartment data. Así es como una carga se autentica sin ninguna credencial, y es el equivalente en OCI de un perfil de instancia. Todo lo que siga usando una clave de firma de API en un fichero de configuración debería migrarse a esto.

Usa condiciones para estrechar. Las políticas de OCI admiten cláusulas where sobre atributos de la petición, etiquetas y recurso destino. allow group Ops to manage instance-family in compartment prod where request.permission != 'INSTANCE_DELETE' es el tipo de cosa que hace seguro repartir un grupo de guardia.

Etiquetas, que aquí trabajan más que en otros sitios

OCI tiene etiquetas libres y etiquetas definidas — con espacio de nombres, tipadas y gobernables. Usa las definidas: un espacio de nombres con Environment, Owner y CostCentre, con valores por defecto aplicados a nivel de compartimento para que todo recurso creado dentro los herede automáticamente.

Esa última función —valores de etiqueta por defecto por compartimento— es de verdad mejor que sus equivalentes en otras nubes, y significa que el problema de recursos sin etiquetar con el que abre el artículo de la factura de AWS aquí se puede sencillamente prevenir.

Después usa políticas basadas en etiquetas: allow group Developers to manage instances in compartment prod where target.resource.tag.Ops.Environment = 'test'.

Regiones y dominios de disponibilidad

Suscríbete solo a las regiones en las que operas, y ten en cuenta que la región de origen es donde vive IAM y no se puede cambiar. Algunas regiones tienen un solo dominio de disponibilidad en vez de tres, lo que cambia sustancialmente tu diseño de alta disponibilidad — compruébalo antes de planificar, porque los dominios de fallo dentro de un único AD no son la misma protección que varios AD.

Terraform y OCI Resource Manager

El proveedor oci es bueno y completo. Un estado por compartimento y capa, guardado en Object Storage o en OCI Resource Manager, que es el servicio gestionado de Terraform de Oracle y es de verdad cómodo para equipos que no quieren mantener su propio pipeline. Autentica la CI con principales de instancia o de recurso en lugar de claves de API, por el mismo motivo por el que las claves son la respuesta equivocada en todas partes.

Montamos esto al inicio de un proyecto de OCI, y es la estructura de la que depende el resto del trabajo cloud.

Qué hacer esta semana

Lista tus compartimentos y, para cada uno, escribe una frase que diga qué política existe para acotar. Aquellos cuya frase hable de un equipo y no de una función son los que hay que replantear, porque los equipos cambian y las funciones no.