Getting Started with OS Management Hub

Get started with OS Management Hub by ensuring service prerequisites are met before registering instances.

Complete the following to get started with the service:

Supported Environments

OS Management Hub can manage OCI instances and on-premises or supported third-party cloud instances. OS Management Hub provides updates as they're made available by OS vendors. Available updates are subject to the vendor's OS lifecycle programs.

Tenancy Requirements

OS Management Hub requires an Oracle Cloud Infrastructure tenancy.
- If you're using Oracle Cloud Applications, you might not have the required access. Contact your sales representative. Learn more about Oracle's cloud services.
OS Management Hub isn't available on the Oracle Cloud Free Tier.

Subscription Requirements

For on-premises or third-party cloud instances, you must have a valid Oracle Linux Basic and Premier Support subscription to use OS Management Hub.

Supported OS Versions

OCI instances

Oracle Linux 6, 7, 8, or 9
Windows Server 2016, 2019, or 2022 Standard, Datacenter
Oracle Autonomous Linux 7 or 8 (managed by the Autonomous Linux service which uses OS Management Hub for automated patching)

Important

OS Management Hub requires minimum Oracle Cloud Agent version 1.40. For instances using platform images released before April 2024, upgrade the Oracle Cloud Agent to 1.40 or later.

On-premises or third-party cloud instances

Oracle Linux 7, 8, or 9

Supported third-party clouds

OS Management Hub can manage Oracle Linux instances in the following third-party clouds:

Amazon Web Services (AWS)
- For information on how to create an Oracle Linux instance in AWS, see Launch an Oracle Linux Instance in AWS.
Microsoft Azure

Compartment Considerations

You can specify which compartment the following resources reside in. This can be useful to limit access to resources on a per compartment basis.

Software sources: Vendor software sources always reside in the root compartment, but can be replicated to other compartments. Custom software sources can reside in any compartment.
Profiles: Service-provided profiles and default profiles always reside in the root compartment. All other profiles can reside in any compartment. See Understanding Profiles.
Management stations: Can reside in any compartment.
Groups: Can reside in any compartment.
Lifecycle environments: Can reside in any compartment.

Best Practices

When creating groups or lifecycle environments, limit instance members to the same compartment as the group or lifecycle environment. OS Management Hub displays instance members, jobs, and reports for a single compartment at a time. When all instance members are in the same compartment, you have a direct view of all members, jobs, and reports associated with the group or lifecycle environment.

If instance members are in several compartments, your view of instances, jobs, and reports is limited to the selected compartment. You must change the compartment scope when viewing members, examining job logs, and running reports. For example, when looking at a job for a multi-compartment group, you would need to change compartments to view all the associated children jobs. Additionally, depending on your policies, a user might not have permissions to all the compartments for the instance members. These users will have an incomplete view of the group or lifecycle environment.

Moving Resources Between Compartments

You can move most resources between compartments within the same region of your tenancy. However, any scheduled jobs associated with the resource don't move to the destination compartment. They continue to reside in the source compartment. For example, if you move a group, any scheduled jobs associated with the group remain in the old compartment.

Before moving resources, verify that policies and permissions are correctly set so that you don't accidentally lose access to the resource.

To move resources, see:

For general information about moving resources between compartments in OCI, see Moving Resources Between Compartments.

Networking Considerations

OCI instances

Oracle Linux

Attach instances to a virtual cloud network (VCN) that has one of the following:

A private subnet with a service gateway that uses the All <region> Services in Oracle Services Network CIDR label.
A private subnet with a NAT gateway.
A public subnet with an internet gateway.

For detailed instructions, see Access to Oracle Services: Service Gateway.

Windows

Define the security lists or network rules to allow Windows instances access to the Windows update server. For more information, see Windows OS Updates for Windows Images.

On-premises or supported third-party cloud instances

Ensure the instance acting as the management station can reach the OCI network.

For Microsoft Azure, verify that your Azure Virtual Network allows traffic on the proxy and mirror listening ports for your management station.
For Amazon Web Services (AWS), verify that your Amazon Virtual Private Cloud (VPC) allows traffic on the proxy and mirror listening ports for your management station.

For more information, see Creating a Management Station.

Required IAM Policy

For policy management, define groups of users and dynamic groups of resources. Then create policies that grant permissions to the groups instead of individual users or resources. See Example Policies for specific use cases. See Getting Started with Policies for general information on policies.

Recommended User Group

Create a user group to administer the OS Management Hub service in the tenancy. Any user that belongs to the group automatically inherits the policies and permissions with that specific group. For more information about user groups, see Managing Groups.

Required Dynamic Group

Create a dynamic group to include the instances that OS Management Hub will manage. OCI instances require a different dynamic group rule statement than on-premises or third-party cloud instances (non-OCI). If managing multiple instance types, include both statements. You can use a single dynamic group that contains rule statements for both instance types.

As new instances register with the service, the dynamic group will include instances based on the rule statements. Dynamic group rules are compartment specific, therefore you must specify a rule for every compartment and subcompartment with instances that you want managed by OS Management Hub. For more information on dynamic groups, see Managing Dynamic Groups .

Understanding ANY and ALL

When defining a dynamic group, you set how the group matches the rules defined in 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).
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.

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.

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.

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

When using ALL, the rule won't include any instances because it's impossible for an instance to be in more than one compartment. Don't use ALL with a rule statement that has multiple compartments.

Creating the Dynamic Group

Important

Understand the differences when using ALL and ANY conditions for dynamic groups. See Understanding ANY and ALL.

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

Tip

A single resource can belong to a maximum of five dynamic groups. A good practice is to reuse the same dynamic group wherever possible across services instead of creating new dynamic groups.
For the overall matching rule setting select: Match any rules defined below.
Create rule statements for the instances that OS Management Hub will manage.
Rule for OCI instances
Add a rule statement to include 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 instances.
```
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.

Required Policy Statements

Create a policy with statements that allow instances to register with OS Management Hub and users to manage and operate the service. Before creating the policy, create the recommended user group and required dynamic group. You can set the IAM policy for OS Management Hub either at the tenancy or compartment level.

Note

Policy statements use the default identity domain unless you define the identity domain before the group or dynamic group name (for example, <identity_domain_name>/<dynamic_group_name>). For more information, see Policy Syntax.

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 <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 <user_group> to manage management-agents in tenancy
allow group <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 <user_group> to manage osmh-family in compartment <compartment_name>