Policies
What Is a Policy?
A policy defines what actions are allowed or denied on which resources in Krutrim Cloud.
Policies are written as JSON documents containing permission rules (called statements). A policy does not grant access by itself—it only takes effect when attached to a role.
Key Characteristics
Policies cannot be attached directly to users or groups
Policies have no effect without roles
All permission evaluation happens at the role level
Users get access only through roles/groups
Policy Rule Model
Every policy follows a structured rule model.
Core Policy Fields
Policy Name
Unique identifier for the policy
Yes
Description
Purpose of the policy
Yes
Access Rules
Each policy consists of one or more rules with the following fields: Policy Type: Service or capability namespace Operations: Usually CRUD Effect: Allow / Deny Resource Name:Resources affected
Yes
Access Rule Fields
Field
Description
Example
Policy Type
Target cloud service
All, Security Group, VPC, Virtual machine, Krutrim Certificate Manager, Krutrim Block Storage, Krutrim Object Storage, DNS, Krutrim Kubernetes System, Auto Scaling Groups, Load Balancer, Krutrim Ai Pods, Finetuning, Evaluation, IAM, Model Registry, DBaaS, MaaS, Inference, Billing, SSH Keys.
Resource Name
Resources affected
set to * by default)
Operations
Allowed or denied actions
Create, Read, Update and Delete
Effect
Permission outcome
Allow or Deny
Allow vs. Deny Logic
Allow → Grants permission
Deny → Explicitly blocks permission
Evaluation Order:
Deny statements are evaluated first
If any deny matches → access is blocked
If no deny matches → allow statements are evaluated
If no allow matches → access is denied by default
Important: Deny always overrides allow.
Policy Creation Flow
Define policy (name, description)
Specify Access Rule (service, resource, operation, effect)
Save the policy
Attach policy to role(s)
Assign role to users or groups
Note: A policy has no effect until attached to a role.
Managing Policies
Editing a Policy
You can edit a policy to:
Update name or description
Add, Remove or Modify statements
remove conditions
Steps:
IAM → Policies
Select policy → Edit
Make changes → Save
Editing a policy immediately affects:
All roles using the policy
All users assigned to those roles (directly or via groups)
Changes may:
Grant new access
Revoke existing access
Change / Break user workflows
Best Practices:
Communicate changes in advance
Review attached roles before editing
Avoid frequent edits to widely-used policies
Prefer creating new policies instead
Deleting a Policy
Policies cannot be deleted while attached to roles.
Steps:
Detach policy from all roles
Return to policy
Click Delete
Warning: Deletion is permanent.
Policy Types by Service
Policies are organized by service and by access level.
Default (System-Managed) Policies
Krutrim Cloud provides predefined policies for common use cases.
FullAccess
Full control over the service
ReadAccess
Read Only access
ReadWriteAccess
Read and modify (no delete)
Characteristics:
Created and maintained by the system
Cannot be edited or deleted
Evaluated like regular policies
The service names in the list above are the exact ones that can be used when accessing IAM programmatically
Custom Policies
Custom (customer-managed) policies are defined and maintained by users that grant fine-grained, reusable permissions to identities while enforcing the principle of least privilege.
Characteristics:
Created and maintained by the Root or IAM users (if permission given)
Can be edited or deleted
Policy JSON Examples
Example 1: Full Access Default Policy
Example 2: Read Only Access Default Policy
Example 3: Custom Policy (Explicit Deny)
Example 4: Custom Policy - Allow Kubernetes (KKS) Cluster Creation
To allow IAM users to create any resource, the root user needs to ensure that the IAM user is given all permissions to access / view the other services which are required to create the main resource, for example:
To allow an IAM user to create a Kubernetes (KKS) cluster, the necessary KKS permissions must be supplemented with permissions for other services. Specifically, during the KKS cluster creation process, the user needs the ability to view and select supporting resources, such as those related to VPC.
Next Steps
Attach policies to roles
Assign roles to users or groups
Use groups to scale access
Review custom operations for fine-grained control
Last updated
Was this helpful?

