001. Role Assignment Changes to PIM-Eligible
Date: 03-13-2025
State: Proposed/Accepted/Deprecated/Superseded
Status: Accepted
Context
Multiple Azure subscriptions within the organization host critical resources and workloads. Historically, key roles—such as Owner, Key Vault Secrets User, and Key Vault Secrets Officer—were permanently assigned, creating standing privileges that increase the risk of unauthorized changes or breaches if compromised. Additionally, compliance requirements and internal governance policies call for stricter oversight of elevated permissions.
To address these potential gaps, the organization is reassessing how access to resources is granted and managed. The goal is to reduce long-standing privileges, align with best practices for least privilege, and enhance auditing and accountability.
As part of this reassessment, we will also remove all members (except subscription owners) from the AZAPPL * groups—previously used to nest other groups. This step eliminates unnecessary group nesting and ensures that OSDU platform team receives PIM-eligible role assignments directly at the subscription level, rather than through chained group memberships. This streamlined approach reduces complexity, improves clarity of ownership, and aligns with just-in-time (JIT) security practices.
Below is an updated changelog table showing the old vs. new assignments—including how the osdu-data-landing-zone-ops group (now osdu-platform-team) was previously nested in AZAPPL * groups for Test/Prod, and how we're removing that nesting and instead assigning PIM roles directly to the osdu-platform-team group. The table also shows how the Owner role in Test/Prod/s032 is now assigned to a new osdu-admins group instead of osdu-platform-team.
Roles Involved
- Owner
- Contributor
- Key Vault Secrets User
- Key Vault Secrets Officer
- Azure Kubernetes Service RBAC Cluster Admin
- Azure Kubernetes Service Contributor
| Environment | Role | Before | After |
|---|---|---|---|
| Dev | Owner |
|
|
| Dev | Key Vault Secrets User |
|
|
| Dev | Key Vault Secrets Officer |
|
|
| Dev | Azure Kubernetes Service RBAC Cluster Admin |
|
|
| Dev | Azure Kubernetes Service Contributor |
|
|
| Test | Contributor |
|
|
| Test | Owner |
|
|
| Test | Key Vault Secrets User / Officer / AKS Roles |
|
|
| Prod | Contributor |
|
|
| Prod | Owner |
|
|
| Prod | Key Vault Secrets User / Officer / AKS Roles |
|
|
| s032 | Contributor |
|
|
| s032 | Owner |
|
|
| s032 | Key Vault Secrets User / Officer / AKS Roles |
|
|
To be Access Model Architecture
Decision
We have agreed to use Privileged Identity Management (PIM) eligible, time-bound assignments for all key roles across Development, Test, and Production environments—replacing permanent role assignments with a just-in-time access model that reduces standing privileges and aligns with the principle of least privilege.
Consequences
- By removing permanent high-privilege assignments, the risk of accidental misuse or malicious activity is significantly lowered, which also aligns better with regulatory and audit requirements.
-
PIM logs every activation event, providing clearer visibility into who accessed which role and when. This makes it easier to investigate incidents and monitor usage patterns.
-
Users accustomed to permanent privileges may encounter additional steps when performing elevated tasks. Clear communication, training, and efficient workflows will be needed to mitigate potential friction.
-
Implementing and maintaining PIM policies (e.g., configuring role settings, notifications, approvals) may require more oversight than a permanent assignment model. Teams must plan for the ongoing maintenance of these policies.