When Resource Access Management (RAM) system policies don't meet your requirements, create custom policies to enforce the principle of least privilege and implement fine-grained access control for Compute Nest resources.
What is a custom policy?
RAM policies fall into two categories: system policies and custom policies. Custom policies give you full control over permission definitions and can be tailored to your business requirements.
Key behaviors of custom policies:
Attach to grant permissions: After creating a custom policy, attach it to a RAM user, RAM user group, or RAM role. The policy permissions are granted to that principal immediately upon attachment.
Detach before deletion: To delete a custom policy that is attached to a principal, detach it from the principal first.
Version control: Custom policies support version control through RAM's version management mechanism, so you can track and roll back policy changes.
Authorization information
Before writing a custom policy, review the complete list of available actions for Compute Nest:
Service provider actions: RAM authorization for service providers
Customer actions: RAM authorization for customers
These pages list every action, its description, and the resource types it applies to — use them to build policies beyond the examples below.
Sample policies
Prevent delete operations on the service provider side
To protect services and data from accidental deletion, use a policy similar to the following example. This policy denies delete operations across services, service instances, artifacts, datasets, container image repositories, and virtual internet resources on the service provider side.
{
"Version": "1",
"Statement": [
{
"Effect": "Deny",
"Action": [
"computenestsupplier:DeleteService",
"computenestsupplier:DeleteServiceInstances",
"computenestsupplier:DeleteArtifact",
"computenestsupplier:DeleteAcrImageRepositories",
"computenestsupplier:DeleteAcrImageTags",
"computenestsupplier:DeleteDataset",
"computenestsupplier:DeleteDatasetAsset",
"computenestsupplier:DeleteServiceTestCase",
"computenestsupplier:DeleteVirtualInternetService",
"computenestsupplier:DeleteVirtualInternetEndpoint",
"computenestsupplier:DeleteVirtualInternetSupplierDomain"
],
"Resource": [
"*"
],
"Condition": {}
}
]
}Allow read-only access to service instances on the customer side
To let a RAM user view service instance information without being able to modify or delete anything, use a policy similar to the following example.
{
"Version": "1",
"Statement": [
{
"Effect": "Allow",
"Action": [
"computenest:GetServiceInstance",
"computenest:GetServiceInstanceSubscriptionEstimateCost",
"computenest:ListServiceInstanceActionTrailEvents",
"computenest:ListServiceInstanceBill",
"computenest:ListServiceInstanceResources",
"computenest:ListServiceInstanceUpgradeHistory",
"computenest:ValidateServiceInstanceName",
"computenest:ListServiceInstanceDatasetAutoExportConfigs",
"computenest:ListServiceInstanceLogs",
"computenest:ListServiceInstances"
],
"Resource": [
"*"
],
"Condition": {}
}
]
}