Crea tu primer equipo compartido
Al final de este tutorial habrás creado un equipo compartido e invitado a tres personas a él, cada una con un conjunto de permisos deliberadamente distinto: una lead de operaciones que dirige el equipo, un desarrollador que configura un producto, y una mánager que solo lee los números. Seguimos a BananaSeed, una empresa cuya fundadora está incorporando un equipo.
Necesitas un plan de pago que incluya equipos compartidos (Equipo o Apex). En Solo o Alpha tienes solo tu equipo Personal, que es solo tuyo. Mira facturación para los planes, qué es un equipo para el concepto, y permisos y alcance para el modelo del que beben los roles de abajo.
El montaje
La fundadora de BananaSeed, Ana, se ha quedado sin espacio en su equipo Personal. Tiene dos productos, cada uno con su propia clave de sitio, y tres personas que incorporar:
| Persona | Rol | Debería poder |
|---|---|---|
| Dana | DevOps | Dirigir el equipo: gestionar miembros y access tokens. |
| Raj | Desarrollador | Personalizar la clave de sitio de un producto, y nada más. |
| Mia | Mánager | Ver los números de todo el equipo. No cambiar nada. |
Cada uno mapea a uno de los cuatro permisos: Dana necesita manage, Raj necesita edit en una clave, Mia necesita read.
1. Crea el equipo y sus claves
Desde la lista de equipos del dashboard, crea un equipo llamado BananaSeed. Empieza solo contigo, la dueña, con todos los permisos. Crea las dos claves de sitio en él, shop.bananaseed.com y blog.bananaseed.com, para que haya algo a lo que acotar a la gente. (Mira claves de sitio.)
2. Invita a Dana, la lead de DevOps (manage)
En la página de Miembros del equipo, invita a Dana por correo. La invitación es la dirección de correo en sí; cuando Dana inicia sesión con esa dirección, su membresía queda activa.
Concédele solo manage. Ese único permiso es la administración del equipo: puede añadir, quitar y cambiar miembros y access tokens, y renombrar o eliminar el equipo. Como manage es de todo el equipo, su alcance no importa, así que déjalo en todas las claves de sitio. No necesita read, create ni edit para hacer su trabajo; manage es el permiso de dirigir el equipo.
Ahora Dana puede quitarle a Ana el resto del onboarding de las manos: puede emitir un token de CI, añadir a la siguiente contratación y ajustar permisos, todo sin que el alcance pueda dejarla fuera.
3. Invita a Raj, el desarrollador de un producto (edit, acotado)
Invita a Raj de la misma forma. Él lleva la tienda, no el blog, así que:
- Concédele edit (y read para que vea lo que está editando). Edit le deja configurar la clave: sus ajustes, la rotación del secreto, la verificación alojada, y la personalización de juego y white-label de la clave.
- Fija su alcance a claves de sitio concretas y elige solo
shop.bananaseed.com.
Deja manage apagado. Raj debería configurar su producto, no dirigir el equipo. Con edit acotado a una clave, eso es exactamente lo que obtiene: puede afinar el reto y el skin de la tienda, y no puede tocar el blog, la lista de miembros ni los tokens.
Esta es la concesión de mínimo privilegio del día a día: un permiso (edit) acotado por un alcance (una clave).
4. Invita a Mia, la mánager que solo lee (read)
Invita a Mia y concédele solo read, en todas las claves de sitio. Read le deja abrir cada clave del equipo y mirar su estadística, configuración y audit logs, y no cambiar nada de ello. Obtiene la foto de todo el equipo que necesita para reportar, sin poder editar un ajuste ni rotar un secreto por accidente.
5. Confirma cada concesión
Haz que cada persona inicie sesión y compruebe que el equipo se comporta como se pretende:
- Dana ve los controles de Miembros y tokens y puede cambiarlos, pero editar la propia configuración de una clave de sitio no es su concesión.
- Raj puede abrir y configurar
shop.bananaseed.com, no veblog.bananaseed.com, y no tiene controles de Miembros. - Mia puede abrir cualquier clave y leer su estadística, pero todo control de edición está ausente.
Ese es el sentido entero del modelo: tres personas, tres trabajos, tres alcances distintos, ninguna con más de lo que necesita. En Apex, todo lo que hace cada una queda registrado bajo su propia identidad en el audit log del equipo.
A dónde ir después
- Añade una credencial de CI o de servicio en lugar de una persona con un troop access token, que lleva los mismos permisos y alcance.
- Fija overrides una vez en el equipo para que ambas claves hereden la marca.
- Vigila el uso entre ambos productos en la estadística del equipo.
Véase también
- Permisos y alcance: los cuatro permisos por completo.
- Asientos: cómo cada miembro y token consume el pool de asientos de tu plan.
- Qué es un equipo: el concepto y lo que posee un equipo.