--- type: tutorial title: Crea tu primer equipo compartido summary: Levanta un equipo compartido e invita a tres compañeros, cada uno con exactamente los permisos que su rol necesita, siguiendo a BananaSeed mientras forma un equipo. --- 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](/docs/account-management/billing) para los planes, [qué es un equipo](/docs/troops/overview) para el concepto, y [permisos y alcance](/docs/troops/permissions) 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](/docs/troops/permissions): 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](/docs/site-keys/overview).) ## 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](/docs/troops/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](/docs/game-customization/overview) 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](/docs/troops/statistics), 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 ve `blog.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](/docs/audit-logs/troop-log). ## 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](/docs/troops/tokens), que lleva los mismos permisos y alcance. - Fija [overrides](/docs/troops/overrides) una vez en el equipo para que ambas claves hereden la marca. - Vigila el uso entre ambos productos en la [estadística](/docs/troops/statistics) del equipo. ## Véase también - [Permisos y alcance](/docs/troops/permissions): los cuatro permisos por completo. - [Asientos](/docs/troops/seats): cómo cada miembro y token consume el pool de asientos de tu plan. - [Qué es un equipo](/docs/troops/overview): el concepto y lo que posee un equipo.