Dynamic groups with tag-based scoping (illustrative patterns)

Problem

A dynamic group rule that says "every instance in compartment X" is easy to write and easy to regret. The day someone launches a test box or a bastion in that compartment, it silently picks up the same permissions as your production services.

I wanted membership that is predictable and explainable: this instance is in the group because it is in this compartment and carries this tag.

Options and trade-offs

• Compartment-only rules: simple, with broad membership that grows by accident.
• Instance OCID rules: exact, but you edit the rule every time an instance is replaced.
• Compartment plus tag rules: precise enough for most teams, as long as tagging is governed.

My recommendation

I combine a compartment OCID with a defined tag namespace, key and value, joined with ALL so both conditions must be true. Then I treat the tag like an access-control input and restrict who can apply it. Without that last step, anyone who can tag an instance can effectively add it to the group.

Worked example

A rule that requires both the compartment and the tag. The tag here uses a namespace called department and a key called runtime.

ALL {instance.compartment.id = '<apps_compartment_ocid>',
     tag.department.runtime.value = 'payments'}

When a group should cover two compartments, use ANY around the compartment checks and keep the tag condition outside it:

ALL {
  ANY {instance.compartment.id = '<apps_compartment_ocid>',
       instance.compartment.id = '<shared_compartment_ocid>'},
  tag.department.runtime.value = 'payments'
}

The Console rule builder covers the simple cases, but you will type tag rules by hand. Changes to a rule or to a tag are not instant, so I verify the effective membership rather than assuming it, and I keep the rule text in version control next to the policy it supports.

Checklist

1. Define the tag namespace, key and allowed values before writing the rule.
2. Use ALL so the compartment and the tag must both match.
3. Limit who may apply or change the tag through IAM.
4. Keep the rule text and the reason for it in version control.
5. Plan for a delay after rule or tag changes, and verify membership before cutting over.
6. Re-check the effective membership after each deployment.

Where this doesn't apply

Short-lived experiments are better served by an instance-specific rule, or by a throwaway compartment that will be deleted. A tagging scheme is overhead you do not need there.

One honest limitation

The delay before membership changes take effect can surprise a rollout. I stage the change, test that the policy works for the new instances, and only then retire the old rule.

Sources

• OCI Documentation: Managing Dynamic Groups (matching rules)
• OCI Documentation: Tagging Overview
• OCI Documentation: Calling Services from an Instance