Federated engineering org with an over-broad tenancy policy

OCI IAM policies are allow-only; there is no deny rule to subtract from the tenancy-wide grant. The fix is to remove the root policy and rebuild access around role groups and compartment boundaries. Create groups such as ProdAppDev, ProdDba, NetOps, SecurityAudit, and SandboxUsers. Put policies on the narrowest compartment that contains the resources: for example, Allow group ProdAppDev to manage instances in compartment Prod-App and Allow group ProdDba to manage db-systems in compartment Prod-DB. Use read or inspect for audit and use where a role only needs to attach resources; reserve manage for owners. Remember that policies inherit downward, so a policy placed on Prod-App also affects its subcompartments. That is why the tenancy-level policy was so dangerous: it applied everywhere. For CI/CD, do not create user API keys. Use a dynamic group with a narrow matching rule, such as ALL {instance.compartment.id = 'ocid1.compartment.oc1..prod-app'} plus a production tag, and grant only the deployment actions it needs in the target compartment. If CI/CD runs as a resource principal, scope those policies similarly. Separating production and non-production groups prevents a Sandbox compromise from becoming a production incident.

Split the dynamic group into at least ProdAppInstances and SandboxInstances. The production rule should match only the production compartment, for example ALL {instance.compartment.id = 'ocid1.compartment.oc1..prod-app'}, optionally combined with a defined tag such as tag.Environment.value = 'Prod'. The sandbox rule should match only the sandbox compartment. Never use a rule that matches every instance in the tenancy, and do not rely on a copied sandbox OCID. Then replace the tenancy-wide read buckets policy with a policy in the bucket's compartment that grants read objects only to ProdAppInstances; if the instance only needs one bucket, place the policy where that bucket lives and avoid granting manage buckets. Sandbox instances should not receive any prod bucket policy. In Audit, filter on the instance-principal OCID and inspect eventName for GetObject or ListObjects, targetCompartment, and the bucket name. Check principalName to confirm whether the caller is the dynamic group or a user. Also review dynamic-group membership changes and any policy changes in the last 90 days. This shows whether the fix removed the path or merely changed the caller.

Keep a break-glass path that does not depend entirely on Entra ID, because an IdP outage must not prevent recovery. Create a small BreakGlassAdmins group in the OCI identity domain with two named users, require MFA through a sign-on policy, and restrict sign-in by network perimeter if the business allows it. Grant that group manage all-resources in tenancy, but only that group. Store any emergency API key in OCI Vault, rotate it on a defined schedule, and keep the private key offline in a sealed process. Do not leave the old 400-day-old key active while you build the new path. First create the new key and update the runbook and automation that might use it; then disable the old key, watch for 401 errors and Audit events for 24-48 hours, and delete it after the agreed window. Add Events and Cloud Guard alerts for break-glass sign-in, group membership changes, and tenancy-level policy changes. Test the path quarterly by using it to perform a harmless audited action, then rotate the credential. The goal is a narrow, monitored exception, not a permanent shared admin key.