Oracle Cloud Infrastructure Documentation
Try Free Tier

Enabling Instance Security

Enable Instance Security in Cloud Guard.

To enable Instance Security in your tenancy:

Applying an Instance Security Recipe to a New Cloud Guard Target

  1. Open the navigation menu and select Identity & Security. Under Cloud Guard, select Configuration.
  2. Under Targets select Create new target.
  3. On the Create target page, Basic information panel, enter a Target name and an optional Description for the target.
  4. Select the Compartment to assign to the target.
  5. select Next.
  6. On the Configuration panel, under Instance Security recipe select All compute instances and select one of the Oracle-managed Instance Security detector recipes:
    • OCI Instance Security Detector Recipe—Enterprise (Oracle managed)
    • OCI Instance Security Detector Recipe (Oracle managed)
    See Instance Security Detector Recipes.
  7. Review the new target, and select Create.
  8. Under Configuration select the Instance Security tab select Enable/Edit next to Logging configuration details.
  9. On the Logging configuration details page, you can enable Instance Security raw logging for a region.
  10. For the region you want, select Enable Log.
  11. On the Enable log panel, select the Compartment.
  12. Select an existing log group, or create a new one by selecting Create new group. See Log Group Management.
  13. Select how long the log to keep the log, for values between 30 days and 180 days, or set a custom log retention value.
  14. select Enable log.
Note

If you don't enable the Instance Security raw logs here you can enable them from the Logging service Console. See Enabling Logs from the Logging Service.

Applying an Instance Security Recipe to a Cloud Guard Target

  1. Open the navigation menu and select Identity & Security. Under Cloud Guard, select Configuration.
  2. Locate the target that you want to use and select the target name.
  3. Under Configuration, select the Instance Security tab and select Add recipes and choose one of the Oracle-managed Instance Security detector recipes:
    See Instance Security Detector Recipes.
  4. Accept the prompt to add the Instance Security policies to your environment.
  5. In the Add detector recipes dialog, choose the Oracle-managed Instance Security detector recipe you want to use and select Add recipes.
  6. Scroll to the bottom and next to Logging, select Enable/Edit.
  7. For each region you want, select the Actions menu (actions menu) and select Enable Log.
    1. On the Enable log panel, the compartment the target is in is shown. You cannot change it.
    2. Choose an existing log group, or create a new one by selecting Create new group. See Log Group Management.
    3. Choose how long the log to keep the log, for values between 30 days and 180 days, or set a custom log retention value.
    4. select Enable log.

The final step of enabling Instance Security is to add the policy statements in the Console.

Note

If you don't enable the Instance Security raw logs here you can enable them from the Logging service Console. See Enabling Logs from the Logging Service.

Policy Statements for Instance Security

You must add these policies in the Console as part of enabling Instance Security.

The policies let the Instance Security agent access the required resources in the tenancy, and without these policies you won't get any results.

For information about how to enter the policy statements in the Console, see Creating a Policy.

User Policy Statements

These policies provide user permissions to use Instance Security for on-demand queries and scheduled queries. Add them to your user policies, replacing group with the name of an appropriate group of users.

Allow group <group> to { INSTANCE_READ } in compartment <compartment>
Allow group <group> to { WLP_ADHOC_QUERY_READ} in compartment <compartment>
Allow group <group> to { WLP_ADHOC_QUERY_CREATE} in compartment <compartment>
Allow group <group> to { WLP_ADHOC_QUERY_INSPECT } in compartment <compartment>
Allow group <group> to { WLP_ADHOC_QUERY_DELETE } in compartment <compartment>
Allow group <group> to { CG_ADHOC_QUERY_READ} in compartment <compartment>
Allow group <group> to { CG_ADHOC_QUERY_CREATE} in compartment <compartment>
Allow group <group> to { CG_ADHOC_QUERY_INSPECT } in compartment <compartment>
Allow group <group> to { CG_ADHOC_QUERY_DELETE } in compartment <compartment>
Allow group <group> to  { CG_DATA_SOURCE_INSPECT} in compartment <compartment>
Allow group <group> to  { CG_DATA_SOURCE_READ } in compartment <compartment>
Allow group <group> to  { CG_DATA_SOURCE_CREATE } in compartment <compartment>
Allow group <group> to  { CG_DATA_SOURCE_DELETE } in compartment <compartment>

Service Logging Policy Statements

These policies let users access logs. Add them to your user policies, replacing group with the name of an appropriate group of users.

Allow group <group> to { CG_SERVICE_LOGGING_READ } in compartment <compartment>
Allow group <group> to { CG_SERVICE_LOGGING_CREATE } in compartment <compartment>
Allow group <group> to { CG_SERVICE_LOGGING_UPDATE } in compartment <compartment>
Allow group <group> to { CG_SERVICE_LOGGING_DELETE } in compartment <compartment>

Tenancy Policy Statements

These policies let Instance Security access the required resources in the tenancy.

Allow any-user to { WLP_BOM_READ } in tenancy where all { request.principal.id = target.agent.id, request.principal.type = 'workloadprotectionagent'}
Allow any-user to { WLP_CONFIG_READ } in tenancy where all { request.principal.id = target.agent.id, request.principal.type = 'workloadprotectionagent'}
Allow any-user to { WLP_ADHOC_QUERY_READ } in tenancy where all { request.principal.id = target.agent.id, request.principal.type = 'workloadprotectionagent'}
Allow any-user to { WLP_ADHOC_RESULTS_CREATE } in tenancy where all { request.principal.id = target.agent.id, request.principal.type = 'workloadprotectionagent'}
Endorse any-user to { WLP_LOG_CREATE } in any-tenancy where all { request.principal.id = target.agent.id, request.principal.type = 'workloadprotectionagent' }
Endorse any-user to { WLP_METRICS_CREATE } in any-tenancy where all { request.principal.id = target.agent.id, request.principal.type = 'workloadprotectionagent' }
Endorse any-user to { WLP_ADHOC_QUERY_READ } in any-tenancy where all { request.principal.id = target.agent.id, request.principal.type = 'workloadprotectionagent' }
Endorse any-user to { WLP_ADHOC_RESULTS_CREATE } in any-tenancy where all { request.principal.id = target.agent.id, request.principal.type = 'workloadprotectionagent' }

Using Dynamic Groups to Control Access to On-Demand and Scheduled Queries

You must create dynamic groups to work with on-demand (ad hoc) and scheduled queries. The resource type is:

  • For on-demand queries, cloudguardadhocquery.
  • For scheduled queries, cloudguarddatasource.
Note

  • Each query is automatically linked to a dynamic group based on the resource type and optional tags.
  • Access is determined by the dynamic group that the query belongs to.
  • If no policies exist for a query then it gets an unauthorized exception when the query is run.

This example shows how to create a dynamic group for each type of query. For more information, see Managing Dynamic Groups.

  1. Create the dynamic groups:
    Dynamic Group Dynamic Group Statement
    adhoc_query_dg all { resource.type = 'cloudguardadhocquery', resource.compartment.id = 'my-compartment-id'}
    scheduled_query_dg all { resource.type = 'cloudguarddatasource', resource.compartment.id = 'my-compartment-id' }
  2. Next, write policies to grant the read instance access to the newly created dynamic groups for your compartment or tenancy (root compartment).
    allow dynamic-group adhoc_query_dg to read instances in <compartment or tenancy details> where all { request.principal.type = 'cloudguardadhocquery' }
 allow dynamic-group scheduled_query_dg to read instances in <compartment or tenancy details> where all { request.principal.type = 'cloudguarddatasource' }

    For more information on creating policies for tenancies or compartments, see how policies work.

  3. Now, you can create queries:

Using Tags to Isolate Query Permissions

You can use tags to isolate and categorize scheduled queries you are running. For more information about using tags, see Tagging.

Note

To use tags, you must create the on-demand or scheduled queries using CLI or API.
  1. Create the dynamic groups with tags:
    Dynamic Group Dynamic Group Statement
    adhoc_query_dg all { resource.type = 'cloudguardadhocquery', resource.compartment.id = 'my-compartment-id', tag.namespace.tag-key.value = 'tag-value' }
    scheduled_query_dg all { resource.type = 'cloudguarddatasource', resource.compartment.id = 'my-compartment-id', tag.namespace.tag-key.value = 'tag-value' }

    For example, suppose you have a tag namespace called "Departments" and a tag in that namespace called "department_type" with a values list of ["hr", "finance", "marketing", "it"]. The dynamic group statement for a custom query would be

    all { resource.type = 'cloudguardadhocquery', resource.compartment.id = 'my-compartment-id', tag.department_type.tag-key.value = 'finance' }
  2. Write policies to grant the read instance access to the newly created dynamic groups.
    allow dynamic-group adhoc_query_dg to read instances in compartment my-compartment where all { request.principal.type = 'cloudguardadhocquery' }
allow dynamic-group scheduled_query_dg to read instances in compartment my-compartment where all { request.principal.type = 'cloudguarddatasource' }
  3. Now, you can create queries using CLI or API with the tags you've defined:

Was this article helpful?