Example of policy implementation

In this example, a rule is added which allows only the users present in the authorizedUsers list to perform a request for the 'unwrap' route used for Google Drive.

In the policy.rego file:

  • input refers to the data provided by the Stormshield KMaaS to the policy.

  • data refers to the data in the policy.data.json file.

Once the policy.rego file has been compiled into policy .wasm using via the OPA tool, you can add or remove authorized users by updating the content of the authorizedUsers field in the policy.data.json file.

In this example, a user with an email address in the authentication token 'user1@test.com' or 'user2@test.com' will be allowed to use the 'unwrap' route to decrypt a Google Drive document, whereas other users will not be allowed to do so. Other users will be allowed to use the "unwrap" route if it does not imply Google Drive.

The .rego examples provided in this documentation use a syntax that is still supported by OPA but is no longer the recommended style. These examples are not meant for writing production policies. Stormshield recommends following the official OPA documentation, which reflects the most up-to-date best practices.

policy.rego file

Copy 
package cse
 
# ------------------------------------------------------
 
# Deny by default
default allow := false
 
# Allow all other endpoints
allow if {
input.endpoint != "unwrap"
}
 
# Allow access to unwrap endpoint if not concerning drive application
allow if {
input.endpoint == "unwrap"
input.authorization.iss != "gsuitecse-tokenissuer-drive@system.gserviceaccount.com"
}
 
# Allow access to unwrap concerning drive, only for authorizedUsers
allow if {
input.endpoint == "unwrap"
input.authorization.iss == "gsuitecse-tokenissuer-drive@system.gserviceaccount.com"
input.authentication.email in data.authorizedUsers
}

policy.data.json file

Copy 
{
"authorizedUsers": ["user1@test.com", "user2@test.com"]
}