Por que estes primitivos precisam de página própria
O restante deste catálogo IBM Cloud é organizado em torno de roles — o que uma identidade pode fazer. Mas Access Groups e Trusted Profiles respondem a uma pergunta diferente: quem ou o quê pode receber essas roles, e como. São entidades centrais do modelo de identidade do IBM Cloud IAM, equivalentes a Security Groups + Managed Identities de outras clouds — mas até agora apareciam neste site apenas como texto descritivo dentro da role IAM Administrator, sem serem catalogados como entidades próprias.
Access Group
Um contêiner que agrupa usuários, IDs de serviço e trusted profiles para atribuição de política em massa. Em vez de atribuir uma role individualmente a cada identidade, a policy é atribuída uma única vez ao grupo, e todos os membros herdam o acesso.
Membros permitidos
- Usuários IAM (por e-mail ou federados via IdP)
- IDs de serviço (Service IDs)
- Trusted profiles
- Outros access groups não são suportados como membros — sem aninhamento
Casos de uso
- Onboarding/offboarding em massa: adicionar/remover um usuário de um grupo em vez de reatribuir dezenas de policies
- Sincronização automática de membros via SCIM a partir de um IdP corporativo (Entra ID, Okta)
- Regras dinâmicas de associação baseadas em atributos SAML do IdP (ex.: todos os usuários do departamento "Engenharia" entram automaticamente)
Capacidades principais
- Policies atribuídas ao grupo se aplicam a todos os membros, incluindo os adicionados posteriormente
- Suporta "dynamic rules" — associação automática baseada em atributos de federação SAML
- Um usuário pode pertencer a múltiplos access groups; o acesso efetivo é a união de todas as policies
- Access group access review — revisão periódica obrigatória de quem tem acesso a quê
Limites
- Sem aninhamento de access groups dentro de access groups
- Limite de 1.000 access groups por conta (padrão; pode ser aumentado via suporte)
Trusted Profile
Uma identidade IAM sem credenciais de login próprias, criada para ser assumida por uma entidade confiável — um recurso de computação (VSI, cluster), uma identidade federada de outro IdP, ou uma carga de trabalho de outra cloud via workload identity federation (OIDC). É o equivalente funcional a uma IAM Role assumível de outras clouds (ex.: AWS IAM Role, Azure Managed Identity).
Confiado por
- Recursos de computação IBM Cloud (Virtual Server Instances, VPC, clusters de Kubernetes/OpenShift)
- Identidades federadas via IdP compatível com SAML 2.0/OIDC
- Cargas de trabalho de outras clouds (AWS, Azure, GCP) via workload identity federation, sem chaves de API de longa duração
- Serviços do próprio IBM Cloud atuando em nome de um recurso
Casos de uso
- Eliminar chaves de API de longa duração embutidas em código ou pipelines CI/CD
- Conceder a uma VSI ou cluster acesso apenas aos serviços que ela precisa, sem uma identidade de usuário humano por trás
- Federação cross-cloud: uma workload rodando em outra cloud assume um trusted profile para acessar recursos IBM Cloud
- Automação e workloads não-interativos (equivalente a Service Roles/Managed Identities de outras clouds)
Capacidades principais
- Políticas IAM padrão (mesmas roles do restante do catálogo) podem ser atribuídas a um trusted profile
- Sessões obtidas via trusted profile são temporárias e não requerem armazenamento de credenciais estáticas
- Pode ser membro de um Access Group, herdando as policies do grupo
- Suporta condições de confiança (ex.: apenas de uma conta AWS/GCP específica, ou apenas de um cluster com um determinado namespace)
Limites
- Não é uma identidade de login interativo — não pode ser usada para acesso via console com usuário/senha
- A relação de confiança precisa ser configurada explicitamente por tipo de entidade confiável (compute resource, federado, ou cross-cloud)
Access Group vs Trusted Profile vs Service ID
| Primitivo | É uma identidade? | Uso principal | Análogo em outras clouds |
|---|---|---|---|
| Access Group | Não — é um contêiner | Atribuição de policy em massa a múltiplos membros | AWS IAM Group / Azure AD Group (role-assignable) |
| Trusted Profile | Sim — identidade sem credenciais próprias | Acesso federado/cross-cloud e workloads de computação | AWS IAM Role (assumable) / Azure Managed Identity |
| Service ID | Sim — identidade não-humana com chave de API | Automação legada que ainda depende de credenciais estáticas | AWS IAM User (service account) / GCP Service Account com chave |
Recomendação: prefira Trusted Profiles a Service IDs sempre que possível — eliminam a necessidade de rotacionar chaves de API estáticas, que são a causa mais comum de vazamento de credenciais em pipelines de automação.
Como se combinam com as roles do catálogo
- 1
Uma role é definida
Ex.: Editor no serviço Cloud Object Storage — o que pode ser feito.
- 2
A role é atribuída a um Access Group ou diretamente a um Trusted Profile
Atribuir ao grupo escala melhor: novos membros herdam automaticamente.
- 3
Identidades entram no Access Group
Usuários, Service IDs ou Trusted Profiles — manualmente ou via dynamic rules baseadas em atributos do IdP.
- 4
Trusted Profiles são assumidos por entidades confiáveis
Um recurso de computação, uma federação SAML/OIDC ou uma workload de outra cloud assume o profile e herda o acesso efetivo — sem nunca ter uma credencial de longo prazo.
Fontes
| Documento | Link |
|---|---|
| Setting up access groups | cloud.ibm.com |
| Creating a trusted profile | cloud.ibm.com |