Apply one of the Oracle-managed Instance Security detector recipes to a Cloud Guard target. This enables Instance Security in Cloud Guard for your tenancy. See Instance Security Detector Recipes.
You can create a new target, or you can use an existing target. See About OCI Targets.
Applying an Instance Security Recipe to a New Cloud Guard Target
Open the navigation menu and click Identity & Security. Under Cloud Guard, click
Configuration.
Under Targets click Create new target.
On the Create target page, Basic information panel, enter a Target name and an optional Description for the target.
Select the Compartment to assign to the target.
Click Next.
On the Configuration panel, under Instance Security recipe select All compute instances and choose one of the Oracle-managed Instance Security detector recipes:
On the Configuration page, click the Instance Security tab. You can see the Instance Security detector recipe you have applied to the new target. Scroll to the bottom and next to Logging, click Enable/Edit.
For each region you want, click the Actions menu () and select Enable Log.
On the Enable log panel, the compartment the target is in is shown. You cannot change it.
Choose an existing log group, or create a new one by clicking Create new group. See Log Group Management.
Choose how long the log to keep the log, for values between 30 days and 180 days, or set a custom log retention value.
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.
Copy
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.
Copy
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.
Copy
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.
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' }
Next, write policies to grant the read instance access to the newly created dynamic groups.
Copy
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' }
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
Write policies to grant the read instance access to the newly created dynamic groups.
Copy
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' }
Now, you can create queries using CLI or API with the tags you've defined: