Roles

What Is a Role?

Roles define what a user is allowed to do in Krutrim Cloud. They are the primary mechanism used to grant permissions to users in a controlled and reusable way.

A role itself does not represent a person or a team. Instead, it represents a set of permissions that can be assigned to users directly or via groups.

A role is a logical grouping of one or more policies.

Roles:

• Bundle permissions into reusable units

• Enable least-privilege access design

• Allow consistent permission management across users and teams

A role has no effect unless it is assigned to at least one user or group.

---

Permission Model

Roles sit between policies and users in the IAM permission model.

Policy → Role → (User | Group) → User

• Policies define what actions are allowed or denied

• Roles aggregate policies

• Users inherit permissions only through roles

Key characteristics:

• Roles do not inherit from other roles

• Roles cannot exist without policies

• Permissions are evaluated only through roles

---

Managed Roles and Custom Roles

Krutrim Cloud supports two types of roles:

Managed (System-Managed) Roles

Managed (System-Managed) Roles

Managed roles are predefined roles provided by Krutrim Cloud to cover common access patterns.

Managed roles:

• Are created and maintained by the system

• Cannot be edited

• Cannot be deleted

• Behave like regular roles during permission evaluation

Custom Roles

Managed Roles and Permissions

The following managed roles are available by default:

Role Name	Description	Permissions Granted
Account Admin	Full administrative access to the account	All permissions except actions on the root user
Viewer	Read-only access across the account	Read-only access to all resources except billing
Billing	Billing visibility	Read-only access to billing and usage information

---

Creating a Role

To create a custom role:

1. Navigate to IAM → Roles

2. Click Create Role

3. Provide:

   • Role Name

   • Description

4. Attach one or more policies

5. Click Create Role

Requirements:

• At least one policy must be attached

• Role name must be unique within the organization

---

Putting a Role Into Effect

Creating a role does not automatically grant permissions to any user.

To apply a role:

• Assign the role to a user

  1. Navigate to IAM → Users

  2. Open the user

  3. Click Edit

  4. Attach the role

  5. Save changes

OR

• Assign the role to a group

  1. Navigate to IAM → Groups

  2. Open the group

  3. Click Edit

  4. Attach the role

  5. Save changes

The role takes effect immediately for:

• The user (direct assignment), or

• All users who are members of the group

---

Editing a Role

You can edit a role to:

• Update its name or description

• Add policies

• Remove policies

Downstream Impact of Editing

Editing a role has immediate downstream effects.

Any change to a role affects:

• All users directly assigned to the role

• All users who inherit the role via groups

Changes take effect immediately and may:

• Grant additional access

• Revoke existing access

• Break workflows for users

---

Deleting a Role

Roles cannot be deleted while they are attached to users or groups.

To delete a role:

1. Identify all users and groups using the role

2. Navigate to each user or group

3. Remove the role

4. Return to the role

5. Delete the role

Deletion permanently removes the role and its permission bundle.

---

Admin Callouts and Best Practices

Be Careful When Editing Roles

Editing roles can unintentionally impact multiple users at once.

Recommended practices:

• Communicate role changes in advance

• Review attached users and groups before editing

• Avoid frequent changes to widely-used roles

---

Prefer Creating New Roles Over Editing Existing Ones

If additional permissions are required:

Recommended approach

• Create a new role with the additional permissions

• Attach the new role to users or groups

Avoid

• Modifying existing roles that are already widely assigned

This approach:

• Prevents unexpected access changes

• Preserves auditability

• Allows safe rollback by detaching roles

---

Design Roles Around Job Functions

Good role design:

• Maps to job responsibilities (e.g. DevOps, Network Admin, Viewer)

• Remains stable over time

• Uses groups for large-scale assignment

Avoid:

• User-specific roles

• Overloaded “god roles”

• Frequent role churn

---

Next Steps

• Attach roles to Users for direct access

• Use Groups to scale role assignment

• Review Policies to understand how permissions are defined