IAM: one answer to who can do what, everywhere
Cluster RBAC, cloud roles and platform permissions in one model, with time-bound elevation instead of standing admin and access reviews that produce revocations.
What is IAM?
DevOpsArk IAM is the module that models and governs access across Kubernetes clusters, cloud accounts and the DevOpsArk platform itself: least-privilege roles, time-bound elevation, periodic access review and a complete audit trail of privileged action.
What IAM is for
The conditions this module removes. If none of these are familiar, you probably do not need it yet.
- Permissions are spread across cluster RBAC, three cloud IAM systems and the CI tool, so "who can delete production" has no single answer.
- Standing administrator access is granted for an incident in 2023 and never removed.
- Access review is a spreadsheet exercise that ends with everything being approved.
- Leavers keep cluster credentials because revocation happens in one system and not the others.
- Privileged actions are logged per system, so reconstructing an incident means joining four audit logs by hand.
IAM builds one model of effective access across Kubernetes RBAC, cloud provider IAM and DevOpsArk platform roles, so a question about a person or a service account is answered once rather than per system. Standing privilege is replaced with time-bound elevation: a request states what is needed and why, an approver grants it for a fixed period, and it expires automatically. Access reviews are generated from actual usage (showing which granted permissions have never been exercised), which makes revocation an easy decision rather than a contested one. Every privileged action taken through the platform is recorded in one trail, so reconstructing what happened during an incident does not require joining logs from four systems.
What IAM does
The 7 capabilities that make up IAM.
Unified effective-access model
Cluster RBAC, cloud IAM and platform roles resolved into one answer per identity.
Time-bound elevation
Privilege is requested with a reason, approved for a fixed window and expires on its own.
Usage-informed access review
Reviews show which permissions were actually used, so unused grants are revoked without argument.
Role templates by function
Roles defined for platform engineer, developer, on-call and auditor rather than assembled per person.
Unified privileged audit
One trail of privileged action across clusters, clouds and the platform.
Break-glass with accountability
Emergency access is available, recorded, time-limited and reviewed afterwards rather than blocked or invisible.
Coordinated offboarding
Revocation across every connected system as one action, with confirmation per system.
How IAM fits together
Outcomes
- Access questions have one answer instead of four partial ones.
- Standing administrator access goes away without blocking urgent work.
- Access reviews produce revocations because they are based on usage.
- Offboarding is complete and provable.
- Incident reconstruction reads one audit trail.
Using IAM, step by step
The path from connecting a source to getting value, in the order it happens.
- 1Connect identity
Attach the identity provider and the systems whose access should be governed.
- 2Model effective access
RBAC, cloud IAM and platform roles are resolved into one view per identity.
- 3Replace standing privilege
Define elevation paths with approvers and maximum durations.
- 4Review against usage
Periodic reviews show which grants were exercised and which were not.
- 5Audit and offboard
Privileged action is recorded centrally; revocation runs across all systems at once.
Where teams apply IAM
Remove standing admin
Replace permanent elevated roles with time-bound elevation that expires automatically.
Run a meaningful access review
Review against actual usage rather than a list of grants nobody can evaluate.
Answer who can delete a namespace
Resolve effective access across RBAC and cloud IAM in one query.
Offboard completely
Revoke across every connected system in one action, with per-system confirmation.
What IAM works with
Named integrations link to their own page. The rest are supported runtimes and formats.
IAM: frequently asked questions
The 7 questions teams ask most often before adopting IAM.
Identity and access management in DevOps covers who (person or workload) can perform which operations on clusters, cloud accounts, pipelines and the delivery platform itself. The difficulty is that these permissions normally live in separate systems, so the effective answer is hard to determine.
Rather than holding elevated permissions permanently, an engineer requests them when needed with a stated reason. An approver grants them for a fixed window, and they expire automatically. Urgent work is still possible; permanent standing privilege is not.
It reads Roles, ClusterRoles and their bindings across every connected cluster and resolves them into effective permissions per subject, highlighting bindings wider than your baseline. Where write scope is granted, it can also apply changes.
Usage data. A review that lists grants invites blanket approval; a review that shows which grants have never been exercised in six months makes revocation the obvious choice.
It is available rather than blocked, but it is time-limited, recorded with its justification, notified to the security team at the moment of use, and reviewed afterwards. Blocking emergency access simply produces shared credentials.
No. It integrates with Okta, Microsoft Entra ID, Google Workspace or any SAML or OIDC provider, and governs what those identities can do in the infrastructure systems it manages.
Revocation is a single action that runs across every connected cluster, cloud account and platform role, and reports per-system confirmation so an incomplete revocation is visible rather than assumed.
See IAM against your own environment
A 30-minute walkthrough with a platform engineer, not a sales deck. Bring a cluster and a problem.