The compartment move that silently revoked access
Northwind Logistics runs a single OCI tenancy in the Frankfurt region. Until last month the production workload lived in Workloads/App-Prod, and two grants depended on that placement: a tenancy-level policy, "Allow group ProdOps to manage instance-family in compartment Workloads", and a dynamic group dg-app-instances whose matching rule is instance.compartment.id = 'ocid1.compartment.oc1..appprod', granted "read secret-family in compartment Shared". During a reorganisation an administrator with tenancy-admin rights moved App-Prod under a new parent, Legacy/App-Prod, and touched neither the policy nor the dynamic group. Two days later the 40 instances in App-Prod receive 404s when reading secrets from Vault, ProdOps members can no longer terminate or launch instances, and a support engineer insists IAM is broken because "the policies are still there". Separately, the security team is onboarding a managed service provider that has its own identity domain inside the tenancy; the provider's engineers must be able to read secrets in Shared and must not be able to change them.
1. The Vault reads fail even though the dynamic group and its policy are untouched. Explain the mechanism and give two ways to make the grant survive future reorganisations.
Read the worked answer
What actually broke. A dynamic group is not a membership list you join; OCI re-evaluates its matching rule against the resource's attributes on every authorization decision. The rule asks "is this instance currently in compartment ocid1..appprod?" After the move the answer is no, so the instances are no longer members of dg-app-instances. The policy statement is intact and still attached where it was - the principal disappeared, not the grant. Nothing in IAM is broken.
Confirm before changing anything. Get the instance's compartment OCID from the console or oci compute instance get, and compare it with the OCID in the matching rule. Also check whether the instances lost only Vault access or everything; if only Vault broke, the compartment is the only variable.
Option A - tag-based matching rule. Apply a defined tag such as Ops.Workload = app-prod to the instances and write the rule as tag.Ops.Workload.value = 'app-prod'. Defined tags travel with the resource through compartment moves. Freeform tags cannot be used in matching rules, so publish the tag with tag defaults so nobody forgets it at launch.
Option B - decouple identity from placement. Keep the fleet in a stable compartment whose purpose is identity, not reporting structure, and forbid reorganisation of it. For a small fixed fleet, matching on instance.id is even more explicit but needs maintenance on every rebuild.
Process guard. Before any compartment move, search dynamic groups for the moving compartment's OCID; a one-line check would have caught this. Policy grants also change scope on a move (see next question), so treat a compartment move as a change that requires an IAM review.
2. Why did ProdOps lose the ability to launch and terminate instances, and what is the least-privilege policy change that restores it?
Read the worked answer
Scope, not verbs. A policy statement's reach is the compartment it names plus everything beneath it. "in compartment Workloads" covered App-Prod only while App-Prod was a descendant of Workloads. After the move, App-Prod sits under Legacy, which Workloads does not contain, so the statement no longer matches the request and the group falls back to no permission. The word "manage" is not the problem; the path is.
Candidate fixes, ranked by blast radius.
- Attach a policy in compartment Legacy with
Allow group ProdOps to manage instance-family in compartment App-Prod. Only that one compartment is affected, and Legacy is the narrowest place the policy can live while still governing App-Prod. - Attach at the tenancy root with the explicit path:
Allow group ProdOps to manage instance-family in compartment Legacy:App-Prod. Same scope, useful when the team that owns IAM does not own Legacy. - Avoid
in tenancy(grants everywhere) and avoid granting on all of Legacy (grants on every sibling that ever lands there).
Tighten the verb while you are in there. manage includes create and delete. If ProdOps only needs to start, stop and reboot, use instance-family covers working with existing instances without permitting launch or termination. If they genuinely need to terminate, keep manage but consider splitting the group so that only the on-call subgroup can delete.
Verification. Test as a member of the group using a compartment-scoped command, and check for a conflicting deny or a broader policy elsewhere - a grant that is still in place plus a new narrower policy is fine, but a leftover manage all-resources in tenancy would make the exercise pointless.
3. How do you grant the managed service provider read-only access to secrets in Shared, given that they have their own identity domain?
Read the worked answer
The constraint. In OCI IAM with identity domains, a group belongs to exactly one identity domain. You cannot add a user from the provider's domain to an existing group in the default domain, and you cannot create a group that spans domains. So the grant must reference a group that exists inside their domain.
The grant. Ask the provider's domain administrator to create a group, for example VendorReadOnly, containing only the engineers who need access. Then write, from the tenancy (or from Shared, if you hold manage-policy there):
Allow group 'ProviderDomain'/'VendorReadOnly' to read secret-family in compartment Shared
Quote the domain name; names with spaces or mixed case need it. read gives list and get, which is what retrieving secret bundle contents requires, and it does not permit create, update or delete. If the provider must not even see secret names, inspect is narrower still (list only). Do not use manage secret-family, and do not grant on keys - reading a secret's contents is a different permission from using a key to decrypt.
Contain the blast radius. Shared almost certainly holds more than the provider needs. Create a dedicated compartment, move only the secrets under contract into it, and grant on that compartment alone. Then a copy-paste error in a future policy cannot expose the rest.
Operational points. Policy evaluation stays in OCI, so the provider's users are subject to your policy regardless of how they authenticate. Log the grant, set a review date, and remove the group from the policy - not the user from the group - when the contract ends, so the audit trail shows the access change.