Groups

Organize users into groups with inherited permissions

Groups in Cased CD Enterprise allow you to organize users and assign permissions at the group level rather than individually.

How groups work

Groups can come from two sources:

1. Identity Provider (IdP) — Groups defined in your SSO provider (Cognito, Okta, etc.)
2. ArgoCD local accounts — Groups assigned to ArgoCD local users

When a user logs in, their group memberships are used to determine their permissions via ArgoCD’s RBAC system.

Viewing groups

Navigate to Settings → Groups in the Cased CD UI to see:

• All groups in your system
• Members of each group
• RBAC roles assigned to each group

IdP group integration

AWS Cognito

Cognito automatically includes groups in the cognito:groups claim:

# Create a group
aws cognito-idp create-group \
  --user-pool-id us-west-2_XXXXXXXXX \
  --group-name developers \
  --region us-west-2

# Add user to group
aws cognito-idp admin-add-user-to-group \
  --user-pool-id us-west-2_XXXXXXXXX \
  --username user@example.com \
  --group-name developers \
  --region us-west-2

Okta

Configure a groups claim in your Okta application:

1. Go to Applications → Your App → Sign On
2. Edit the OpenID Connect ID Token section
3. Add claim: groups with filter matching your groups

Other providers

Most OIDC providers support a groups claim. Consult your provider’s documentation for configuration details.

RBAC configuration

Map IdP groups to ArgoCD roles in argocd-rbac-cm:

kubectl patch configmap argocd-rbac-cm -n argocd --type merge -p '
data:
  policy.csv: |
    # Define roles
    p, role:developer, applications, get, */*, allow
    p, role:developer, applications, sync, */*, allow
    p, role:admin, applications, *, */*, allow
    p, role:admin, clusters, *, *, allow
    p, role:admin, repositories, *, *, allow

    # Map groups to roles
    g, developers, role:developer
    g, admins, role:admin
    g, platform-team, role:admin
'

Tip

Group names in the RBAC policy must match exactly what your IdP sends in the groups claim.

Common patterns

Team-based access

Give each team access to their applications:

# Frontend team can manage frontend apps
p, role:frontend, applications, *, default/frontend-*, allow
g, frontend-team, role:frontend

# Backend team can manage backend apps
p, role:backend, applications, *, default/backend-*, allow
g, backend-team, role:backend

Environment-based access

Restrict production access:

# Developers can sync to staging
p, role:developer, applications, sync, staging/*, allow

# Only admins can sync to production
p, role:admin, applications, sync, production/*, allow

Read-only access

For stakeholders who need visibility:

p, role:viewer, applications, get, */*, allow
p, role:viewer, logs, get, */*, allow
g, stakeholders, role:viewer

Troubleshooting

Groups not appearing

1. Check IdP configuration — Verify groups claim is included in tokens
2. Verify group membership — Ensure users are assigned to groups in IdP
3. Check ArgoCD logs — Look for OIDC/groups-related errors

kubectl logs -n argocd deployment/argocd-server | grep -i group

Permission denied despite group membership

1. Case sensitivity — Group names are case-sensitive
2. Exact match — Group name in RBAC must match IdP exactly
3. Token refresh — User may need to log out and back in

Viewing user’s groups

Check a user’s effective groups via ArgoCD:

argocd account can-i sync applications '*' --as user@example.com