Rethinking Access with Task-Based and Role-Aware Security

1. Introduction

In many organizations, access control is a balancing act. Assigning permissions directly to users or based on broad job titles often results in employees having more access than they need, increasing security risks and complicating audits. Traditional role-based access control (RBAC) systems, while effective in simpler setups, struggle to keep up with the complexity of modern cloud environments and dynamic technical teams. These models often fail to reflect the specific tasks people perform, leading to inefficiencies and vulnerabilities. This document introduces a task-based access control model designed to align permissions with what people—and systems—actually do. By focusing on real-world workflows, this approach ensures access is secure, auditable, and scalable. It’s built on four intuitive layers:

1. Baseline Permissions: The minimal access rights needed to perform a specific operation on a resource.
   

2. Task-Based Security Groups: Collections of baseline permissions that represent a complete technical task.
   

3. Role-to-Task Mapping: Business roles linked to only the tasks required for daily responsibilities.
   

4. Just-in-Time Access via PIM: Temporary, approval-based access for sensitive or infrequent tasks.
   

This model empowers teams to work efficiently while maintaining a strong security posture. It supports both human users and automated systems, like CI/CD pipelines, making it ideal for organisations navigating complex technical landscapes.

To provide context, this task-based model builds on RBAC but addresses its limitations by incorporating elements of more dynamic systems. For comparison:

Model	Key Basis	Strengths	Weaknesses	When to Use
RBAC (Role-Based)	Predefined roles tied to job functions	Simple, easy to administer, aligns with organizational structure	Static, prone to over-privileging, lacks context awareness	Basic environments with stable roles
ABAC (Attribute-Based)	Dynamic attributes (e.g., user location, time, device)	Highly flexible, context-aware, fine-grained	Complex to implement, requires more resources (e.g., XML coding), performance overhead	Dynamic, high-security scenarios with varying conditions
PBAC (Policy-Based)	Centralized policies combining rules and attributes	Scalable, unified management, supports hybrid models	Can be overly abstract, integration challenges	Enterprise-wide policies needing consistency across systems
Task-Based (Proposed)	Workflow-specific tasks built from baselines	Granular, auditable, reduces drift, integrates JIT	Initial setup effort, requires workflow analysis	Cloud-native, agile teams with frequent changes

This framework enhances RBAC with task focus, offering ABAC-like flexibility without full complexity.

2. Security Model

2.1. Baseline Permissions: The Foundations

Modern cloud platforms like Azure, AWS, and Google Cloud offer highly granular permissions, allowing precise control over resources. However, completing even a simple task often requires combining multiple permissions across different roles or services. This complexity can lead to errors, over-provisioning, or audit challenges. Baseline permissions address this by defining the smallest set of access rights needed to perform a specific operation on a resource. These are not tied to users or roles but act as reusable building blocks, making permissions easier to manage and audit.

In Azure there are special security groups, called Roll-assignable groups, these are different from normal security groups. Whilst you can assign Azure Roles to these groups, group nesting is not supported. This fits into this design, baseline permissions are roll-assignable groups, whilst normal groups allow us to combine these groups into higher level tasks.

Typical Examples

Reduced permissions When looking at access controls there are some, such as Azure’s Virtual Machine Contributor, that combines numerous internal roles. Sometimes, not all these roles are required and it makes sense to combine a more limited set of roles and expose that through a baseline security group. An example of this is to provide the ability for a user of a VM to turn on and off that VM without any other permissions on that VM.

Kubernetes Kubernetes with RBAC, allows security groups to be mapped to Roles within a namespace of the cluster (via Role Bindings). In this scenario, we can create a ‘action’ security groups that can provide read access or admin access to a specific namespace.

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: example-ns
  name: read-pods
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
---
kind: RoleBinding
metadata:
  name: read-pods
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: read-pods
subjects:
- kind: Group
  namespace: example-ns
  name: '00000000-0000-0000-0000-000000000000'

This creates a 'read access' group for a specific namespace, reusable across tasks.

Why Baseline Permissions Matter

• Simplicity: Group related permissions into logical, actionable units.
  

• Reusability: Apply the same baseline permissions across multiple tasks or environments.
  

• Auditability: Provide clear documentation of access rights for compliance reviews.
  

2.2. Task-Based Security Groups: Focused Access for Specific Actions

Task-based security groups take baseline permissions and combine them to represent a complete technical task, such as deploying an application, managing secrets, or reviewing logs. These groups are designed to reflect how work is actually done, ensuring users have just enough permissions to complete their tasks without excess privileges.

For instance, a "deploy app" task might combine baseline permissions for storage writes, network access, and Kubernetes deployments.

Design Principles

• Focused Access: Include only the permissions needed for a specific task.
  

• Separation of Duties: Avoid overlap with other tasks to maintain clear boundaries.
  

• Scalability: Simplify onboarding and access reviews by reusing task groups.
  

• Holistic Scope: Incorporate both identity-based (e.g., cloud roles) and network-based (e.g., VPN access) permissions.
  

2.3. Role-to-Task Mapping: Assigning Staff the Right Access

Roles represent an employee’s responsibilities within the organization, such as “Developer” or “Senior Engineer.” By mapping roles to task-based security groups, we ensure users receive only the access required for their daily work. Importantly, roles are never assigned baseline permissions directly—access is always mediated through task groups to maintain granularity and traceability.

A common scenario is to enable Read access to resources within the cloud environment and assigning these to specific staff.

Benefits of Role-to-Task Mapping

• Alignment with Business Needs: Roles reflect job functions, while tasks define technical access.
  

• Flexibility: New tasks can be added to roles without restructuring the entire model.
  

• Auditability: Clear mappings make it easy to track who has access to what and why.
  

This layered approach ensures that permissions are both meaningful to the business and technically precise, reducing the risk of over-provisioning.

2.4. Just-in-Time Access via PIM: Elevation with Control

Some tasks, such as managing production secrets or updating critical infrastructure, are too sensitive for permanent access. Privileged Identity Management (PIM) provides temporary, just-in-time access to these tasks, balancing security with flexibility.

How PIM Works

• Request-Based Access: Users request access to a task group, providing a justification (e.g., a change request ID).
  

• Approval Workflow: Requests trigger peer or manager approval, ensuring oversight. Importantly, the requested cannot approve their own requests.
  

• Time-Bound Access: Access is granted for a limited duration (e.g., 4 hours) and automatically revoked. This should be mandated on all roles.
  

• Full Audit Trail: All actions are logged for compliance and security reviews.
  

With PIM we can setup additional safeguards that will help protect these security roles.

• MFA updated on request: When a PIM request is made the user can be made to go through an MFA process before the role is granted.
  

• Conditional Access: Limit activation to compliant devices, named locations, or business-hours windows.
  

Example

A developer needs to update a secret in a production Key Vault, which isn’t part of their regular duties. They:

1. Submit a PIM request for TASK_PROD_KEYVAULT_ADMIN.

2. Provide a change request ID or reason for access.

3. Await approval from a peer or manager.

4. Receive temporary access and access revoked after the time limit.

This process ensures developers can perform necessary tasks without delay while maintaining a strong security posture.

2.5. Extending the Model to CI/CD Pipelines

CI/CD pipelines and other automated systems are often granted broad permissions for simplicity, increasing the risk of misuse or compromise. The task-based model applies the same principles to automation, treating pipelines as first-class identities with scoped access.

Example

• Pipeline Identity: ROLE_CI_PROD_DEPLOY
  

• Assigned Task Group: TASK_PROD_DEPLOYMENTThis grants the pipeline only the permissions needed to update container images and deploy to a Kubernetes namespace.
  

Benefits

• Least Privilege for Automation: Pipelines receive only the access required for their tasks.
  

• Consistent Governance: Human and automated actors follow the same access control framework.
  

• Reduced Attack Surface: Scoped permissions minimize risks in CI/CD environments.
  

By treating pipelines like human users, the model ensures consistency and auditability across all actors.

3. Exceptions

There will be cases when the identified tasks are not sufficient. It is important to acknowledge that these will occur and setup appropriate tasks with higher and higher permissions.

These high level roles must be managed using PIM and setup in a way that only senior members of the team can approve. With these roles, it is important that the approver ensures appropriate context is given to the CR and that it is flagged for later review. The review process should then make the decision as to whether a new task is created or not. All activations should trigger alerts so that security teams are aware of these high-level roles being used.

4. High Privileged Roles

The model that we have highlighted can be applied to all tasks including those that rely on highly privileged accounts such as the Global Administrator. However, moving these roles to PIM introduces a dependency on Entra ID services, MFA, Conditional Access policies, and network availability. There are risks that, due to outages, it may not be possible to activate a PIM role. This is where break-glass accounts, also known as emergency access accounts, become essential. These are highly privileged, permanent global administrator accounts designed exclusively for "break-glass" scenarios, where normal access mechanisms fail, ensuring you can regain control of your environment without being completely locked out. Microsoft recommends at least two such accounts, excluded from PIM, MFA, and Conditional Access, to serve as a resilient fallback.

PIM reduces attack surfaces by eliminating permanent admins, but over-reliance on it could create single points of failure. Break-glass accounts should be exempt from PIM to avoid circular dependencies. Best practices include storing credentials securely (e.g., in a physical safe or password manager), monitoring usage with alerts, and rotating them regularly.

5. Audit

Key to ensuring that this model works is the concept that common tasks are assigned by default and uncommon tasks are assigned using PIM. It is important to provide metrics on how often PIM is used as this will give an indication as to the drift between intended and effective permissions. This drift is very informative and can lead to identify issues not only in the permission structure but also undue production access.

There should be at least a quarterly of all roles & tasks and a monthly audit of all high-risk roles and PIM activations.

6. Summary

This task-based security model offers a structured and scalable approach to managing access. Instead of relying on broad, often imprecise role assignments, it builds access from the ground up. Starting with baseline permissions, tasks are constructed to reflect actual workflows. Roles then map cleanly to these tasks based on business needs.

The model also addresses key modern concerns such as the need for temporary elevated access, secure automation, and auditable access boundaries. When implemented correctly, it improves agility, strengthens security, and supports growth in a flexible and manageable way.

Benefits

Enforces Least Privilege: By ensuring that access is limited to only what is necessary for each task, this model reduces the chances of misuse or accidental exposure. No one gets more access than they need by default.

Modular and Scalable: Access control is managed in reusable units, allowing changes to be made at the task level without disrupting the entire structure. As new systems and tasks emerge, the model can be extended without breaking existing roles.

Improves Developer Velocity: Developers and other users can work more efficiently because they are not blocked waiting for approvals for tasks they perform regularly. Just-in-time elevation supports exceptional cases without delay.

Audit-Friendly: Since each access level is clearly defined and roles only include tasks, it's easy to audit who can do what and when. This clarity simplifies compliance reviews and reduces the risk of hidden privileges.

Automation-Ready: By applying the same principles to pipelines and service accounts, the model ensures that automation respects security boundaries, reducing the attack surface in CI/CD environments.

Drawbacks

Initial Setup Complexity: Defining baseline permissions and mapping them to tasks requires thoughtful analysis of systems, operations, and workflows. It can be time-consuming to build the initial structure.

Requires Ongoing Maintenance: As tasks evolve and systems change, baseline and task definitions must be reviewed and updated.

Tooling Dependencies: To fully benefit from this model, identity platforms must support just-in-time access, security group inheritance, and fine-grained auditing. Not all environments have this capability.

Cultural Shift: Teams may be accustomed to broad, role-based access and resist moving to a more precise, task-based system. Change management and communication are important to ensure adoption.

7. Final Thoughts

I developed this security model during a growth phase at the startup where I was planning a new production environment. Several key factors shaped its design, emphasizing security from the outset.

• Company Policies I had recently drafted the IT policy and procedures for onboarding and offboarding employees. These were overly complex, requiring careful management of permissions for new hires and revocations for departures. I wanted to ensure that the new security model prioritised a clear separation between users and resource permissions, embedding least privilege principles right into the architecture.
  

• Auditing As we aimed for ISO 27001 compliance, demonstrating robust internal security audits was essential. I focused on creating a straightforward, testable framework that could verify access controls without ambiguity.
  

• PIMPIM on Azure had just been released in preview; even though there was limited documentation I immediately saw the benefit of this approach I did not want to implement PIM using broad roles as this would violate least privilege by granting excessive access. Alternatively, tight roles demand multiple elevations and complex tracking. Task-based permissions align elevations in response to performing a specific action.
  

With these in mind, I started to view all operations through the lens of tasks and mapped them to roles. Routine tasks (performed more than twice a week) received permanent assignments, while infrequent ones were made available on-demand with time-bound elevations.

I also anticipated edge cases beyond initial tasks, so we incorporated higher-level options for administrative needs across the environment. These required detailed documentation in change requests to justify the escalation, ensuring accountability.

Following this, we transitioned to dedicated admin accounts—a quick implementation that involved reassigning roles from general user accounts to these specialized ones.

By designing with task-based permissions at the core, we aligned access with purpose from the start, granting exactly what's needed for success—no more, no less. Though it required upfront planning, the results were transformative: enhanced security posture, efficient operations, and transparent audit trails that foster trust and resilience.

Examples

Baseline Permissions

The naming of the baseline permissions should follow a naming convention. Key to this is the separation of environment, service and the action to be performed: BASE_<ENV>_<SERVICE>_[<SCPOPE>]_<ACTION>.

• Reading Secrets from Azure Key VaultThere are 2 types of Key Vault reader. For monitoring it is useful to see what secrets are present in the Key Vault without needing to see or read the actual value.

  • BASE_PROD_KV_SECRETS_READLIST BASE_DEV_KV_SECRETS_READLIST

    Grants read-only access to see what secrets are in the Key Vault.
    

  • BASE_PROD_KV_SECRETS_GET BASE_DEV_KV_SECRETS_GET

    Grants access to list and read the contents of the Key Vault.
    

• Managing Key Vault Secrets

  • BASE_PROD_KV_SECRETS_ADMIN BASE_DEV_KV_SECRETS_ADMIN Allows administrative actions, such as creating or updating secrets in a production Key Vault.
    

• Provide access to logging infrastructure

  • BASE_PROD_MONITOR_LOG_VIEWER BASE_PROD_APPINSIGHTS_VIEWER BASE_DEV_MONITOR_LOG_VIEWER BASE_DEV_APPINSIGHTS_VIEWER

    Allows access to monitor the logs and application insights of our application.
    

• Inspecting Kubernetes and Container Registry

  Kubernetes systems involve many components and Roles within a cluster.

  • BASE_PROD_ACR_IMAGE_LIST BASE_DEV_ACR_IMAGE_LIST Grants read access to determine what images have been loaded into the registry.
    

  • BASE_PROD_K8S_NS_A_VIEWER BASE_DEV_K8S_NS_A_VIEWER Grants read access to a specific namespace within a Kubernetes cluster. This will allow access to look at the workloads within that namespace
    

  • BASE_PROD_K8S_CLUSTER_VIEWER BASE_DEV_K8S_CLUSTER_VIEWER Grants read access to a Kubernetes cluster to read its configuration.
    

• Deploying to Kubernetes and Container RegistryDeploying an application often spans multiple systems. For example:

  • BASE_PROD_ACR_IMAGE_PUSHB ASE_DEV_ACR_IMAGE_PUSH Grants write access to a container registry for updating images.
    

  • BASE_PROD_K8S_CLUSTER_ADMIN BASE_DEV_K8S_CLUSTER_ADMIN Allows updates to a Kubernetes cluster.
    

  • BASE_PROD_K8S_NS_A_DEPLOY BASE_DEV_K8S_NS_A_DEPLOY Allows updates to a Kubernetes namespace for deploying applications.
    

• Network Access via VPNSome tasks require network-level access. For instance:

  • BASE_PROD_VPN_ACCESS: Assigns a VPN IP from a production address pool (e.g., 172.16.1.0/24) instead of the default address pool (e.g., 172.16.0.0/24) to access restricted resources securely.
    

Tasks

Now that we have identified the base line security groups. We now have to group these together into specific tasks

• Key Vault Administration

  Consider a scenario where someone needs to manage secrets in a production Azure Key Vault. The Key Vault is protected by a firewall and a private link. This only allows access to the Key Vault for specific VPN address pool (e.g., 172.16.1.0/24).
  

  TASK_PROD_KEYVAULT_ADMIN:

  • BASE_PROD_VPN_ACCESS

  • BASE_PROD_KV_SECRETS_ADMIN
    

  This group ensures a user can securely connect to the production network and manage secrets, with no unnecessary permissions.
  

• Production Monitoring In some cases a production system will only require monitoring. In these scenarios we will only use read tasks.
  

  TASK_PROD_VIEWER:

  • BASE_PROD_ACR_IMAGE_LIST

  • BASE_PROD_K8S_CLUSTER_VIEWER

  • BASE_PROD_K8S_NS_A_VIEWER

  • BASE_PROD_MONITOR_LOG_VIEWER

  • BASE_PROD_APPINSIGHTS_VIEWER
    

  Assigning this group to a user will give them the ability to read the logs and configuration of the production systems.
  

• Production Deployment Deploying an application to a Kubernetes cluster involves updating container images and applying changes to the pods within a specific namespace. TASK_PROD_NS_A_DEPLOYMENT:

  • BASE_PROD_ACR_IMAGE_PUSH

  • BASE_PROD_K8S_NS_A_DEPLOY
    

  Assigning this group to a user or CI/CD pipeline provides the exact access needed to complete a deployment.
  

Roles

Now that the tasks have been defined we can start to assign these tasks to users and allow

• ROLE_DEVELOPER:

  • TASK_DEV_VIEWER

  • PIM: TASK_PROD_VIEWER

  • PIM: TASK_DEV_DEPLOYMENT

  • PIM: TASK_DEV_KEYVAULT_ADMIN
    

  Grants access for the developer to be able to read the current production and development configurations without being able to make any changes. It also enables the developer to gain access to the development system via requesting the role via PIM.
  

• ROLE_SNR_DEVELOPER:

  • Inherits ROLE_DEVELOPER

  • PIM: TASK_PROD_VIEWER

  • PIM: TASK_DEV_DEPLOYMENT

  • PIM: TASK_DEV_KEYVAULT_ADMIN

  • PIM: TASK_PROD_DEPLOYMENT

  • PIM: TASK_PROD_KEYVAULT_ADMIN
    

  We have not extended the number of tasks that were available to developers; we have extended what tasks can be performed via PIM.
  

• ROLE_CI_PROD_DEPLOY

  • TASK_PROD_DEPLOYMENT
    

  This role is assigned to the service principle/managed identity associated with the CI pipeline agent. It gives it just enough permissions to update the container image and deploy the updated application.