# 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: {% tabs %} {% tab title="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 {% endtab %} {% tab title="Custom Roles" %} #### Custom Roles Custom roles are created and managed by your organization. Custom roles allow you to: * Combine multiple policies * Create fine-grained, least-privilege access * Tailor permissions to specific job functions Custom roles: * Can be edited * Can be deleted (after detaching) * Are reusable across users and groups {% endtab %} {% endtabs %} ### 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 ``` ``` --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.cloud.olakrutrim.com/basics/identity-access-management/roles.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.