RBAC Integration
Clophi uses your existing Azure role assignments as the source of truth for what users can see and do in the platform. A user's capabilities in Clophi are derived directly from their permissions in Azure.
Clophi never elevates a user beyond their Azure permissions and never performs deployments under a more privileged identity than the requesting user. Every action executed through Clophi runs in the security context of the signed-in user.
How permissions are evaluated
Clophi refreshes role assignments every 5 minutes. On each refresh, it fetches the user's role assignments across the management groups, subscriptions, and resource groups they have access to. Built-in roles, custom roles, and role assignments are all included. By processing all the role definitions (both Custom or Built-in) down to the specific Actions, DataActions, and NotActions levels, Clophi ensures that even custom least-privilege roles function instantly out of the box with zero extra configuration.
The resulting set of allowed actions determines what the user can do in Clophi. Newly granted roles become effective on the next refresh cycle.
Default permission requirements
Below is a list of certain actions in Clophi together with the required RBAC permissions to use them:
- Loading resource forms: loading any resource form is possible by default.
- Creating infrastructure: write permissions on the chosen deployment scope for every resource type listed in the deployment. If you don't have the adequate permissions on the scope you want to deploy these resources, that scope will not be presented to you within the Subscription and Resource Group dropdowns in the infrastructure section.
- Listing deployed resources: read and write permissions at the scope where those resources live.
Note: All above actions are possible if only they are not blocked to the user by the organization's Clophi Admin over Clophi Permissions. See Clophi Permissions for Clophi level access control options.
Having write permission on a resource type does not guarantee that infrastructure using that resource will deploy successfully. Many resources reference others, and Azure enforces these references with dedicated sub-actions. For example if you want to link a Public IP for a Network Interface Card write permission will not be enough. Attaching the Public IP to the NIC requires Microsoft.Network/publicIPAddresses/join/action on the IP. Without it, the NIC deployment fails even though the Public IP itself was created.
Customizing RBAC rules
The mapping between Azure roles and Clophi capabilities is configurable per organization. Each capability can be bound to a specific role definition or a combination of role definitions. Configurable capabilities include loading resource forms, creating infrastructure, accessing built-in architectures, creating custom draft resources, listing deployed resources, and exporting infrastructure.
Common adjustments:
- Require only the Reader role to load resource forms, with form output limited to template download rather than direct deployment.
- Allow Reader alone to list deployed resources, decoupling visibility from edit rights.
- Restrict infrastructure creation to a broader role like Contributor.
