User-defined roles improve security and compliance through refined permission control. The core is to customize permissions based on specific needs to avoid excessive authorization. Applicable scenarios include regulated industries and complex cloud environments. Common reasons include reducing security risks, assigning permissions closer to responsibilities, and following the principle of least authority. Control granularity can be read to a specific bucket, virtual machine starts and stops but cannot be deleted, restricts API access to endpoints, etc. The creation steps are: Identify the required action set → Determine the resource scope → Configure roles using platform tools → Assign to users or groups. Practical recommendations include streamlining permissions with built-in roles as templates, testing non-critical accounts, and keeping the role concise and focused.

User-defined roles let you create custom sets of permissions that fit your specific needs, especially in cloud platforms or enterprise systems. Unlike built-in roles like "Admin" or "Viewer," user-defined roles allow you to define exactly what someone can or can't do — down to the action and resource level.

Why Use User-Defined Roles?

Most platforms come with pre-built roles, but they're often too broad. For example, a developer might only need access to certain databases or development tools, not everything in the environment. Using a user-defined role lets you avoid giving more access than necessary.

Here are some common reasons people create custom roles:

• Reduce security risks by limiting unnecessary permissions
• Align with job responsibilities more closely than standard roles allow
• Follow least privilege principles , which is key for compliance

You'll usually find yourself reaching for user-defined roles when managing teams in regulated industries or complex cloud environments.

How Granular Access Control Works

Granular access control means being able to specify permissions at a very detailed level. With user-defined roles, you can do things like:

• Allow read-only access to specific storage buckets
• Permit starting and stopping virtual machines, but not deleting them
• Restrict API access to certain endpoints or regions

Each platform has its own syntax and interface for defining these roles. In Azure, for instance, you write JSON files specifying allowed actions and resources. In AWS, you use IAM policies attached to custom roles.

The trick is understanding what actions are available and how to structure the rules correctly. Most platforms provide documentation on available operations and how to format them.

When and How to Create One

Creating a user-defined role isn't complicated, but it does require knowing what you're trying to restrict or allow.

You typically go through these steps:

• Identify the exact set of actions users should be able to perform
• Decide which resources those actions apply to (like specific projects, folders, or services)
• Write or configure the role using the platform's tooling
• Assign the role to users or groups

For example, if you want a data analyze to only view specific dashboards and query certain datasets, you'd create a role with just those permissions and assign it to their account.

Some tips:

• Start with a built-in role as a template, then remove unneeded permissions
• Test new roles with non-critical accounts before rolling out widely
• Keep role definitions simple and focused — avoid bundling unrelated permissions

It's easy to overcomplicate this, but most platforms make it straightforward once you understand the permission model.

Basically that's it.

The above is the detailed content of What are user-defined roles, and how do they provide granular access control?. For more information, please follow other related articles on the PHP Chinese website!