Securing OS Management Hub

OS Management Hub manages, monitors, and controls the OS software content of instances, ensuring that they're up-to-date with the latest security patches. Follow these security best practices to secure OS Management Hub.

Security Responsibilities

To use OS Management Hub securely, learn about your security and compliance responsibilities.

In general, Oracle provides security of cloud infrastructure and operations, such as cloud operator access controls and infrastructure security patching. You are responsible for securely configuring your cloud resources. Security in the cloud is a shared responsibility between you and Oracle.

Oracle is responsible for the following security requirements:

  • Physical Security: Oracle is responsible for protecting the global infrastructure that runs all services offered in Oracle Cloud Infrastructure. This infrastructure consists of the hardware, software, networking, and facilities that run Oracle Cloud Infrastructure services.

Your security responsibilities are described on this page, which include the following areas:

  • Access Control: Limit privileges as much as possible. Users should be given only the access necessary to perform their work.
  • Patching: Keep software up-to-date with the latest security patches to prevent vulnerabilities.

Initial Security Tasks

Use this checklist to identify the tasks you perform to secure OS Management Hub in a new Oracle Cloud Infrastructure tenancy.

Task More Information
Use IAM policies to grant access to users and resources IAM Policies
Configure groups to control access to the service Recommended User Group
Add only the software sources you require to the service Selecting Software Sources
Use profiles to control the software sources attached to an instance Selecting Software Sources
Configure regular mirror syncs for the management stations Syncing Mirrors

Routine Security Tasks

After getting started with OS Management Hub, use this checklist to identify security tasks that we recommend you perform regularly.

Task More Information
Apply the latest security patches Patching Software
Use Ksplice to apply security updates Patching Software
Monitor mirror sync status and create sync jobs Syncing Mirrors
Remove unnecessary packages on instances Removing Unnecessary Packages
Review reports to verify security compliance Reviewing Reports

IAM Policies

Use policies to limit access to OS Management Hub.

For OS Management Hub, you must identify which resources the service can manage and which users can manage those resources. To do this, define the following:

IAM policies specify which users and services can access certain OCI resources. If you're new to policies, see Getting Started with Policies. You can configure IAM policies in various ways. The following sections provide one example of how to set the IAM policy statements for a group of OS Management Hub administrators by using a dynamic group of resources. See Example Policies for additional non-administrator use cases.

User Group

Create a user group or identify an existing user group to administer the OS Management Hub service in the tenancy. The required policy statements then grant this administrator user group the ability to manage OS Management Hub resources.

If you need to further restrict access, you can create additional user groups and set more restrictive policy statements to limit access to specific resources. See Example Policies for non-administrator use cases. For more information about user groups, see Managing Groups.

Dynamic Group

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:
  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.

Policy Statements

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.

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.

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:

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>

Selecting Software Sources

Only add the minimal number of vendor software sources you require to the service. When creating custom software sources use filters or specify a package list to further reduce the content available to instances. Only include the packages necessary to support your workload.

When creating a software source profile, only include software sources that are required. This minimizes the number of packages available to the instance reducing the package installation footprint. Similarly, when creating a group or lifecycle environment only attach the minimal set of software sources necessary.

Syncing Mirrors

Regularly sync mirrored software sources to ensure the management station distributes the latest software packages to instances.

By default a mirror sync job runs once a week. Adjust this frequency based on your security requirements. You can edit the mirror sync schedule as needed. Also, monitor the status of the management station's mirror syncs and run an on-demand mirror sync job at anytime.

Patching Software

Ensure that your managed instances are running the latest security updates.

Keep instance software up-to-date with security patches. We recommend that you periodically apply the latest available software updates to instances registered with OS Management Hub. Consider using multiple update jobs to keep instances up-to-date. For example, apply zero-downtime Ksplice updates often and apply regular security updates on a slower cadence.

Creating Update Jobs

To ensure instances receive regular updates, you can create a job to schedule recurring updates, see:

Running Ksplice Updates

Use Oracle Ksplice to apply critical security patches to Linux kernels on instances without requiring a reboot. Ksplice also updates the glibc and OpenSSL user space libraries, applying critical security patches without disrupting workloads. Create a recurring update job that applies Ksplice updates.

Removing Unnecessary Packages

Remove unnecessary packages from instances to reduce the installation footprint and prevent potential security issues.

Removing a software source doesn't remove packages that were installed from the software source. For example, suppose you're moving from UEK R6 to UEK R7. You add the software source for UEK R7 and then remove the software source for UEK R6. Any installed UEK R6 packages remain on the system. Those packages, however, are no longer updated because the software source has been removed and thus could appear in security scans.

For information about removing packages, see:

Reviewing Reports

OS Management Hub generates reports for security updates, bug updates, and instance activity. Review these reports to identify any instances that are out-of-date. See Viewing Reports.