Pular al contenido

Referencia de Control de Acceso

Capgo utiliza control de acceso basado en roles (RBAC) para gestionar qué puede hacer cada miembro del equipo. Los roles se organizan por ámbito desde toda la organización hasta un solo paquete.

Para una guía visual de la gestión de miembros en la consola, consulte Organización.


Cada rol pertenece a un ámbito que determina qué recurso concede acceso.

Ámbitocontexto: Página/área: Soporte / página de soporte premium o sección de soporte en el pie de página. Rol: Título de sección o página. Visto en: página support-policy.astro. Clave de mensaje `support_policy_scope_title` (Título de política de soporte por ámbito).Ejemplo de uso
OrganizaciónLa organización completa y todos sus aplicativosTu socio fundador obtiene Super Administrador; tu contador obtiene Administrador de Facturación
AplicaciónUna sola aplicación y sus canalesUn contratista que trabaja en una aplicación obtiene Desarrollador de Aplicación
CanalesUn solo canal dentro de una aplicaciónUn ingeniero de pruebas solo gestiona el staging canal
PaqueteA una versión de paquete únicaUn revisor necesita acceso de lectura a una versión de lanzamiento específica

Un miembro puede tener un rol por ámbito objetivo por ejemplo, un rol de organización, un rol en App A y un rol diferente en App B.


Estos roles se asignan cuando se invita a un miembro. Otorgan acceso a toda la organización.

RolNombre internoDescripción
Administrador principalorg_super_adminPropietario-equivalente. Control total incluyendo la eliminación de la organización, la gestión de facturación y la transferencia de aplicaciones. Se concede automáticamente al creador de la organización.
Administradororg_adminAdministración completa — gestionar miembros, aplicaciones, canales. No se puede eliminar la organización, actualizar la facturación, transferir aplicaciones o promover a usuarios a Super Administrador.
Gerente de facturaciónorg_billing_adminAcceso solo a facturación: ver y actualizar información de facturación, facturas e historial de auditoría de facturación. Sin acceso a aplicaciones o miembros.
Miembroorg_memberMatriz de permisos de la organización

Sección titulada “Matriz de permisos de la organización”

Permiso
DescripciónSuper AdministradorMatriz de permisos de la organizaciónAdministradorGerente de facturaciónMiembro
org.readVer la organización
org.update_settingsEditar nombre, logo y correo electrónico de administración de la organización
org.deleteEliminar la organización permanentemente
org.read_membersVer la lista de miembros
org.invite_userInvitar nuevos miembros
org.update_user_rolesCambiar roles de miembros (el administrador no puede promover a Super Administrador — bloqueado por jerarquía de roles)
org.read_billingVer información de facturación y plan actual
org.update_billingActualizar método de pago y plan
org.read_invoicesVer facturas
org.read_auditVer el registro de actividad de la organización
org.read_billing_auditVer el registro de auditoría específico de facturación

puede hacer, en todas las aplicaciones y canales. El rol de la aplicación

Título de la sección “Roles de la aplicación”

Limitado a una sola aplicación. Utilice estos cuando un miembro del equipo debe trabajar solo en una aplicación, no en toda la organización.

RolNombre internoDescripción
Administrador de la aplicaciónapp_adminControl total de una aplicación — canales, dispositivos, roles de usuario para la aplicación. No se puede eliminar ni transferir la aplicación (estos son operaciones de nivel de organización).
Desarrollador de la aplicaciónapp_developerSubir paquetes, gestionar dispositivos, desencadenar compilaciones nativas, actualizar configuraciones de canal. Sin eliminación, sin cambios en la configuración de la aplicación, sin creación de canales.
Subidor de la aplicaciónapp_uploaderAcceso de lectura + subir nuevas versiones de paquetes.
Lector de la aplicaciónapp_readerLectura solo — estadísticas, paquetes, canales, registros, dispositivos.
Vista previa de la aplicaciónapp_previewVida cíclica de la vista previa vinculada a la organización y la aplicación: subir un paquete y crear un canal de vista previa. Crear ese canal concede automáticamente derechos de vida cíclica solo para él.

Matriz de permisos de la aplicación

Matriz de permisos de la aplicación
PermisoDescripciónAdministrador de la aplicaciónDesarrollador de la aplicaciónSubidor de la aplicaciónLector de la aplicación
app.readVer detalles de la aplicación, estadísticas y metadatos
app.update_settingsEditar ajustes de la aplicación
app.read_bundlesVer la lista de paquetes subidos
app.upload_bundleSubir una nueva versión de paquete
app.create_channelCrear un nuevo canal
app.read_channelsVer canales
app.read_logsVer registros de entrega de actualizaciones
app.manage_devicesAsignar, sobreescribir o desvincular dispositivos
app.read_devicesVer lista de dispositivos
app.build_nativeDesencadenar una construcción nube nativa
app.read_auditVer registro de actividad de nivel de aplicación
app.update_user_rolesAdministrar asignaciones de roles de nivel de aplicación
bundle.deleteEliminar un paquete

Conjunto de permisos de vista previa de la aplicación

Sección titulada “Conjunto de permisos de vista previa de la aplicación”

Use Vista previa de la aplicación (app_previewpara una clave de CI organización- y aplicación-vinculada que gestione el ciclo de vida de una vista previa de PR sin acceso amplio a la aplicación o a nivel de organización.

El app_preview El enlace concede solo estos permisos de nivel de aplicación:

PermisoPermite
app.readLeer la aplicación seleccionada
app.read_bundlesLeer los paquetes cargados
app.upload_bundleCargar un paquete
app.create_channelCrear un canal

Cuando una clave de vista previa de la aplicación crea un canal, Capgo da automáticamente a esa clave un hijo channel_preview El

PermisoPermite
channel.readLee el canal creado por la clave
channel.promote_bundleEstablezca el paquete subido por la clave en ese canal
channel.deleteElimine ese canal

Porque app_preview conserva app.read, la clave puede enumerar los metadatos del canal en la aplicación seleccionada. La vinculación automática de hijo es un límite de gestión: no concede mutaciones de ciclo de vida para un canal que la clave no creó. Los registros de __CAPGO_KEEP_0__ recuerdan la clave de vista previa que creó cada canal y subió cada paquete. Por lo tanto, una clave de vista previa de aplicación puede crear cada canal de vista previa no público que necesita, promover su propio paquete y eliminar ese canal y paquete de manera atómica con

Capgo records the preview key that created each channel and uploaded each bundle. Therefore an App Preview key can create each non-public preview channel it needs, promote its own bundle, and atomically delete that channel and bundle with channel delete --delete-bundleNo incluye

, la gestión de dispositivos o roles, app.update_settings, device or role management, channel.update_settings, channel.rollback_bundle, gestión de dispositivos forzada, o genérica bundle.delete.


Limitado a un solo canal. Útil para dar acceso objetivo a un canal de liberación específico.

RolNombre internoDescripción
Administrador de canalchannel_adminControl total de un canal: configuración, promoción/retorno de paquetes, gestión de dispositivos forzados.
Vista de canalchannel_readerLeer solo — paquete actual, historia, dispositivos forzados, registro de auditoría.
Vista previa de canalchannel_previewAsignado por el sistema a la clave de vista previa de App que creó el canal: lectura, promoción de su propio paquete y eliminación de ese canal.

Matriz de permisos de canal

Matriz de permisos de canal
PermisoDescripciónAdministrador de canalVista de canalVista previa de canal
channel.readVer el canal y su paquete actual
channel.update_settingsEditar ajustes del canal (tornillos de plataforma, política de actualización…)
channel.deleteEliminar el canal
channel.read_historyVer historial de asignación de paquetes
channel.promote_bundleEstablecer el paquete activo en el canal
channel.rollback_bundleVolver a un paquete anterior
channel.manage_forced_devicesForzar dispositivos específicos a este canal
channel.read_forced_devicesVer la lista de dispositivos forzados
channel.read_auditVer el registro de actividad del canal

Limitado a una versión de paquete única. Raramente necesario — la mayoría de los equipos utilizan roles de aplicación en su lugar.

RolNombre internoDescripción
Administrador de paquetebundle_adminLeer, actualizar metadatos y eliminar un paquete específico.
Vista de paquetebundle_readerAcceso de lectura a un paquete específico.

En el panel de control, el acceso a los canales se determina por defecto por el rol de la aplicación del usuario. Para un control más detallado, puede sobreescribir permisos de canal específicos por usuario o grupo sin cambiar su rol de aplicación.

Los overrides se configuran desde la aplicación en la pestaña de acceso Acceso pulsando el botón de permisos de canal (ícono de escudo) junto a un usuario. Consulte Organización — Sobreescribiendo permisos de canal para una guía visual.

PermisoDescripciónComportamiento por defecto
LeerVer el canal y su paquete actualHerencia del rol de aplicación
HistorialVer el historial de asignación de paqueteHerencia del rol de aplicación
Asociar paqueteEstablecer o cambiar el paquete activo en el canalHerencia del rol de aplicación

Cada permiso se puede configurar como:

  • Predeterminado — heredar del rol de aplicación (por defecto)
  • Permitir — conceder explícitamente, sin importar el rol de aplicación
  • Denegar — bloquear explícitamente, sin importar el rol de la aplicación

Esto te permite, por ejemplo, dar a un lector de aplicación la capacidad de asociar paquetes en el staging canal sin promoverlos a desarrollador de aplicación.


Los roles forman una jerarquía. Un rol padre hereda todos los permisos de sus hijos. Esto significa que un org_admin puede hacer todo lo que un app_admin puede hacer, lo que a su vez puede hacer todo lo que un channel_admin puede hacer, y así sucesivamente.

Super Admin (org_super_admin)
└── Admin (org_admin)
└── App Admin (app_admin)
├── App Developer (app_developer)
│ └── App Uploader (app_uploader)
│ └── App Reader (app_reader)
├── Bundle Admin (bundle_admin)
│ └── Bundle Viewer (bundle_reader)
└── Channel Admin (channel_admin)
└── Channel Viewer (channel_reader)

Cómo funciona en la práctica:

  • Un Administrador en el nivel de la organización puede hacer todo lo que un Administrador de Aplicación puede, en cada aplicación de la organización.
  • Un Administrador de Aplicación en una aplicación específica puede hacer todo lo que un Administrador de Canal puede, en cada canal de esa aplicación.
  • Un Desarrollador de Aplicación puede hacer todo lo que un Subidor de Aplicación puede, más aún.

La jerarquía solo fluye hacia abajo — nunca gana permisos de nivel de organización, incluso si también tienen un rol de nivel de aplicación. channel_admin Grupos


__CAPGO_KEEP_0__ grupos y asignar roles al grupo. Cada miembro del grupo hereda esos roles automáticamente.

  • Un grupo pertenece a una organización — no puede abarcar varias orgs.
  • Los grupos pueden contener vinculaciones de roles en cualquier ámbito: org, app, canal o paquete. Por ejemplo, un grupo puede ser asignado el Desarrollador de Aplicación rol en App A y el Administrador de Canal papel en el staging canal de App B.
  • Cuando se evalúan las permisos de un usuario, todos sus pertenecimientos a grupos se resuelven de manera transparente. Si alguno de sus grupos concede el permiso requerido, se permite el acceso.
  • Un usuario puede pertenecer a grupos múltiples, y los permisos de todos los grupos son adicionales.
  • Las permisiones basadas en grupos solo se aplican a principales de usuario — las llaves API no heredan roles de grupo.
EscenarioSin gruposCon grupos
5 ingenieros de pruebas necesitan acceso de desarrollador a 3 aplicaciones15 vinculaciones de roles individuales1 grupo + 3 vinculaciones de roles
Alguien se une al equipo de pruebasAgregar 3 vinculaciones de roles manualmenteAgregarlos al grupo
Alguien deja el equipo de pruebasEliminar 3 vinculaciones de roles manualmenteEliminarlos del grupo

Todos los puntos finales de grupo requieren autenticación y se sirven bajo /private/groups.

Ventana de terminal
curl -X GET "https://api.capgo.app/private/groups/<ORG_ID>" \
-H "authorization: <API_KEY>"

Requiere org.read_members permiso.

Ventana de terminal
curl -X POST "https://api.capgo.app/private/groups/<ORG_ID>" \
-H "authorization: <API_KEY>" \
-H "Content-Type: application/json" \
-d '{
"name": "QA Team",
"description": "Quality assurance engineers"
}'

Requiere org.update_user_roles permiso (Administrador principal o ¿Qué alternativas tenemos?).

Ventana de terminal
curl -X PUT "https://api.capgo.app/private/groups/<GROUP_ID>" \
-H "authorization: <API_KEY>" \
-H "Content-Type: application/json" \
-d '{
"name": "QA Team",
"description": "Updated description"
}'

Eliminar un grupo

Eliminar un grupo
Ventana de terminal
curl -X DELETE "https://api.capgo.app/private/groups/<GROUP_ID>" \
-H "authorization: <API_KEY>"

Eliminar un grupo también elimina todas sus vinculaciones de rol. Los miembros no se eliminan de la organización.

Ventana de terminal
curl -X GET "https://api.capgo.app/private/groups/<GROUP_ID>/members" \
-H "authorization: <API_KEY>"
Ventana de terminal
curl -X POST "https://api.capgo.app/private/groups/<GROUP_ID>/members" \
-H "authorization: <API_KEY>" \
-H "Content-Type: application/json" \
-d '{ "user_id": "<USER_UUID>" }'

El usuario ya debe ser miembro de la organización. Agregar un miembro existente es una operación sin efecto.

Ventana de terminal
curl -X DELETE "https://api.capgo.app/private/groups/<GROUP_ID>/members/<USER_UUID>" \
-H "authorization: <API_KEY>"

Ventana de terminal
curl -X GET "https://api.capgo.app/organization/members" \
-H "authorization: <API_KEY>" \
-H "Content-Type: application/json" \
-d '{ "orgId": "<ORG_ID>" }'

Respuesta:

[
{
"uid": "user-uuid",
"email": "alice@example.com",
"image_url": "https://...",
"role": "org_admin",
"is_tmp": false
}
]
Ventana de terminal
curl -X POST "https://api.capgo.app/organization/members" \
-H "authorization: <API_KEY>" \
-H "Content-Type: application/json" \
-d '{
"orgId": "<ORG_ID>",
"email": "bob@example.com",
"invite_type": "org_admin"
}'

Valores aceptados para invite_type:

ValorRol asignado
org_super_adminAdministrador principal
org_adminAdministrador
org_billing_adminGerente de facturación
org_memberMiembro

Eliminar un miembro

Eliminar un miembro
Ventana de terminal
curl -X DELETE "https://api.capgo.app/organization/members" \
-H "authorization: <API_KEY>" \
-H "Content-Type: application/json" \
-d '{
"orgId": "<ORG_ID>",
"email": "bob@example.com"
}'

Asignar roles a través de CLI

Asignar roles a través de CLI

Listar organizaciones

Listar organizaciones
Ventana de terminal
npx @capgo/cli organization list --apikey <API_KEY>
Ventana de terminal
npx @capgo/cli organization members <ORG_ID> --apikey <API_KEY>

Los roles incorporados cubren la mayoría de las estructuras de equipo. La creación de roles personalizados está en nuestra ruta de desarrollo — si esto es algo que necesita su equipo, contactenosSu caso de uso ayudará directamente a priorizar esta función.

Siga adelante desde la Referencia de Control de Acceso

Sección titulada “Siga adelante desde la Referencia de Control de Acceso”

Si está utilizando Referencia de Control de Acceso para planificar operaciones de panel de control y API API Overview API Overview para obtener detalles de implementación en __CAPGO_KEEP_0__ Overview Introducción API Keys para el detalle de implementación en API Claves Dispositivos para el detalle de implementación en Dispositivos, y Paquetes para el detalle de implementación en Paquetes.