Getting Started with OS Management Hub

Create a dynamic group to specify the resources OS Management Hub will manage by defining rule statements for OCI and on-premises or third-party cloud instances (non-OCI).

1. Ensure you understand the following:
   • What does the dynamic group do?
   • Why are there different statements for OCI and non-OCI?
   • When to use ANY and ALL for a dynamic group?

2. Follow the steps to create a dynamic group or update an existing dynamic group and configure the matching rules as follows.

   Tip
   
   

   Reuse the same dynamic group wherever possible across services instead of creating new dynamic groups because a single resource can only belong to a maximum of five dynamic groups.

3. For the overall matching rule setting select: Match any rules defined below.

4. Create rule statements for the instances that OS Management Hub will manage.

   Important
   
   

   Dynamic group rules don't use compartment inheritance. You must specify a rule statement for every compartment and subcompartment that you want managed by the service.

   Rule for OCI instances

   Add a rule statement that includes each compartment (and subcompartment) that will contain instances.

   ANY {instance.compartment.id='<compartment_ocid>',instance.compartment.id='<subcompartment_ocid>'}

   This rule will include all OCI instances in the specified compartments.

   Rule for non-OCI instances

   Add a separate rule statement for each compartment (and subcompartment) that will contain a Management Agent used by an instance.

   ALL {resource.type='managementagent', resource.compartment.id='<compartment_ocid>'}
   ALL {resource.type='managementagent', resource.compartment.id='<subcompartment_ocid>'}

   Each rule statement will include every Management Agent resource in the specified compartment. Each non-OCI instance has a corresponding agent resource and therefore the statement will include the non-OCI instances in the compartment.

5. Click Create (if creating) or Save (if updating).

What does the dynamic group do?

The dynamic group identifies the instances that OS Management Hub will manage. You add rule statements for the compartments and subcompartments that contain instances you want managed by the service. The dynamic group grows and shrinks dynamically based on these rule statements. As instances are provisioned or retired, the dynamic group changes accordingly. The required policy statements then grant OS Management Hub the ability to access the instances within the dynamic group.

For more information on dynamic groups, see Managing Dynamic Groups .

Why are there different statements for OCI and non-OCI?

Each instance type uses a different agent which corresponds to a different resource object.

• OCI instances use Oracle Cloud Agent (OCA) so the OCI statement specifies instance resources within a compartment.

• On-premises and third-party cloud instances use Management Agent Cloud Service (MACS) so the non-OCI statement specifies managementagent resources within a compartment. Each Management Agent resource corresponds to a non-OCI instance. Therefore by including the Management Agent in the group, you're including the associated instance.

See also Understanding the Agent.

When to use ANY and ALL for a dynamic group?

Before writing dynamic group rule statements, it's important to understand the difference between ANY and ALL.

When defining a dynamic group, you set how the group matches the rules defined within the group:

• Match any rules defined below includes resources that match any of the rules within the dynamic group. Select this if defining a group that includes rules for multiple compartments or multiple instance types (such as OCI and non-OCI instances). This setting tells the group to include resources that match rule 1 OR rule 2 OR rule 3, and so on.
• Match all rules defined below includes resources that match all the rules within the dynamic group. Select this when defining a vary narrow dynamic group that includes only one compartment. This setting tells the group to include resources that match rule 1 AND rule 2 AND rule 3, and so on.

When defining individual rule statements within the dynamic group, you set the conditions for each statement:

• All of the following (ALL) includes only resources that match all the conditions in the rule. ALL statements requires each condition to be true. Otherwise, resources aren't included for the rule.

• Any of the following (ANY) includes resources that match any of the conditions in the rule.

Examples of ANY and ALL for an individual rule statement

Consider the rule used for non-OCI instances.

Correct usage:
ALL {resource.type='managementagent', resource.compartment.id='<compartment_ocid>'}

When using ALL, the rule includes only Management Agent resources in the specified compartment. The statement tells the dynamic group to include resources that match the management agent type AND are within the specified compartment.

Incorrect usage. Do not use:
ANY {resource.type='managementagent', resource.compartment.id='<compartment_ocid>'}

When using ANY, the rule includes every Management Agent resource in the entire tenancy and every OCI resource present in the specified compartment. While the statement will include the resources needed for OS Management Hub, it's very broad and typically not preferable.

Consider the rule used for OCI instances when specifying multiple compartments.

Correct usage:
ANY {instance.compartment.id='<compartment_ocid>',instance.compartment.id='<subcompartment_ocid>'}

When using ANY, the rule includes every instance in each of the specified compartments. The statement tells the dynamic group to include instances in <compartment_ocid> OR <subcompartment_ocid>.

Incorrect usage. Do not use:
ALL {instance.compartment.id='<compartment_ocid>',instance.compartment.id='<subcompartment_ocid>'}

When using ALL, the rule tells the dynamic group to include instances that are in <compartment_ocid> AND <subcompartment_ocid>. This rule won't include any instances because it's impossible for an instance to be in more than one compartment at the same time. Don't use ALL with a rule statement that specifies multiple compartments.

Create a policy with statements that allow instances to register with OS Management Hub and users to manage and operate the service. The following policy statements provide an example of how to set a policy for administrators using the service. For other use cases, see Example Policies.

You can set the IAM policy for OS Management Hub either at the tenancy or compartment level.

Prerequisites

Before creating the policy, ensure you have the following:

• User Group (<admin_user_group> in the examples)
• Dynamic Group (<osmh_dynamic_group> in the examples)

Tenancy-level policy statements

To apply the required IAM policy at the tenancy level, use the following policy statements:

allow dynamic-group <osmh_dynamic_group> to {OSMH_MANAGED_INSTANCE_ACCESS} in tenancy where request.principal.id = target.managed-instance.id
allow group <admin_user_group> to manage osmh-family in tenancy

Include the following additional statements if managing on-premises or third-party cloud instances. These aren't required if managing only OCI instances.

allow group <admin_user_group> to manage management-agents in tenancy
allow group <admin_user_group> to manage management-agent-install-keys in tenancy

Compartment-level policy statements (if not using tenancy-level)

If the tenancy administrator doesn't permit setting IAM policies at the tenancy level, you can restrict the use of OS Management Hub resources to a compartment and its subcompartments (policies use compartment inheritance).

To apply the IAM policy to a compartment inside the tenancy, use the following policy statements:

allow dynamic-group <osmh_dynamic_group> to {OSMH_MANAGED_INSTANCE_ACCESS} in compartment <compartment_name> where request.principal.id = target.managed-instance.id
allow group <admin_user_group> to manage osmh-family in compartment <compartment_name>

Include the following additional statements if managing on-premises or third-party cloud instances. These aren't required if managing only OCI instances.

allow group <admin_user_group> to manage management-agents in compartment <compartment_name>
allow group <admin_user_group> to manage management-agent-install-keys in compartment <compartment_name>