Enabling Instance Security
Enable Instance Security in Cloud Guard.
To enable Instance Security in your tenancy:
- 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.
- Add the Instance Security policies to your tenancy.
Applying an Instance Security Recipe to a New Cloud Guard Target
The final step of enabling Instance Security is to add the policy statements in the Console.
Applying an Instance Security Recipe to a Cloud Guard Target
The final step of enabling Instance Security is to add the policy statements in the Console.
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
.
- 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.
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 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.
To use tags, you must create the on-demand or scheduled queries using CLI or API.
- 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' }
- 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' }
- Now, you can create queries using CLI or API with the tags you've defined: