Por que estes dois têm página própria
O resto do catálogo IBM Cloud gira em torno de role — o que uma identidade pode fazer. Access group e trusted profile respondem a outra pergunta: quem, ou o quê, pode receber essas roles, e por qual caminho. São peças centrais do modelo de identidade do IBM Cloud IAM, o equivalente a security group e managed identity das outras clouds — e até aqui apareciam neste site só como texto solto dentro da role Administrator, sem serem catalogados como entidade própria.
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 | Equivalente em outras clouds |
|---|---|---|---|
| Access Group | Não — é um contêiner | Anexar policy uma vez e alcançar vários membros | AWS IAM Group / Entra ID role-assignable group |
| Trusted Profile | Sim — identidade sem credencial própria | Acesso federado, cross-cloud e carga de trabalho de computação | AWS IAM Role (assumable) / Azure Managed Identity |
| Service ID | Sim — identidade não humana, com chave de API | Automação antiga que ainda depende de credencial estática | AWS IAM User (service account) / GCP service account key |
Prefira trusted profile a service ID sempre que der: some a chave de API estática, e chave estática em pipeline é a origem mais comum de vazamento de credencial.
Como isso se encaixa nas roles do catálogo
- 1
A role define o que pode ser feito
Por exemplo, Editor no Cloud Object Storage.
- 2
A role vai para um access group, ou direto para um trusted profile
Atribuir ao grupo escala melhor: quem entra depois já herda.
- 3
As identidades entram no access group
Usuário, service ID ou trusted profile — na mão, ou por regra dinâmica sobre atributo vindo do IdP.
- 4
O trusted profile é assumido por quem se confia
Um recurso de computação, uma federação SAML ou OIDC, uma carga de trabalho de outra cloud — assume o profile e passa a ter o acesso, sem nunca ter tido credencial de longo prazo.
Fontes de dados
| Documento | Link |
|---|---|
| Setting up access groups | cloud.ibm.com |
| Creating a trusted profile | cloud.ibm.com |