Policies & ABAC

Nembl includes an Identity and Access Management (IAM)-style policy engine that provides fine-grained access control beyond what roles alone can achieve. Policies use an Allow/Deny model with support for Attribute-Based Access Control (ABAC) through tag-based conditions.

RBAC vs ABAC — when to use which

Nembl gives you both. Pick by the question you're trying to answer:

Layered approach: assign a Role first (gives broad permissions). Then add Allow/Deny policies only for the specific cases the Role doesn't capture cleanly. Don't try to encode everything in policies — Roles handle 80%+ of real cases with much less maintenance.

Policy Model

Each policy is a JSON document with the following structure:

{
  "effect": "Allow" | "Deny",
  "resource": "service",
  "actions": ["read", "write", "delete"],
  "conditions": {
    "tags": {
      "department": "engineering",
      "environment": "production"
    }
  }
}

Resource Types

Policies can target the following resource types (all singular):

Use wildcards to match all resources (*) or all actions (*).

About secret:reveal: Vault metadata (name, tags, last-rotated date, bound resources) is gated by secret:read; decrypting the stored value is gated by the separate secret:reveal action. Workflow authors picking a vault in phase config need only read; an agent that fetches a value at runtime needs reveal. See Creating & Managing Vaults for the rationale.

Creating a Policy

1. Navigate to Settings > IAM > Policies.
2. Click Create Policy.
3. Select the effect (Allow or Deny).
4. Choose the resource type from the dropdown.
5. Select the actions this policy governs.
6. Optionally add tag conditions (see ABAC below).
7. Assign the policy to a user, group, or role.
8. Click Save.

Policy Evaluation Rules

Nembl uses a two-tier evaluation model that distinguishes between inherited policies (from roles, groups, and teams) and direct user policies.

Evaluation Order

1. Gather all applicable policies -- from the user's roles, groups, team memberships, and direct assignments.
2. Check for explicit Deny -- if any inherited policy denies the action, it is denied by default.
3. Check for direct Allow override -- if a policy assigned directly to the user allows the action, it overrides an inherited Deny.
4. Check for explicit Allow -- if any policy allows the action and no Deny applies, the action is allowed.
5. Default Deny -- if no policy matches, the action is denied (implicit deny).

Key Rule: Direct Allow Overrides Inherited Deny

This is the most important evaluation rule. If a group policy denies workflow:write but the user has a direct policy that allows workflow:write, the direct Allow wins. This allows admins to create broad group-level restrictions while granting targeted exceptions to specific users.

Inherited Deny (from group)    +    Direct Allow (on user)    =    Allowed
Inherited Deny (from group)    +    No direct policy          =    Denied
Direct Deny (on user)          +    Any Allow                 =    Denied

A direct Deny on the user always wins -- it cannot be overridden.

Attribute-Based Access Control (ABAC)

ABAC extends the policy model with tag-based conditions. Instead of writing a separate policy for every resource, you tag resources and write policies that match tags.

Tagging Resources

Resources in Nembl can be tagged with key-value pairs:

1. Open any service, workflow, or other resource.
2. Navigate to the Tags section.
3. Add tags as key-value pairs (e.g., environment: production, department: engineering, sensitivity: high).

Writing Tag-Based Policies

A policy with tag conditions only applies when the target resource has matching tags:

{
  "effect": "Deny",
  "resource": "workflow",
  "actions": ["delete", "write"],
  "conditions": {
    "tags": {
      "environment": "production"
    }
  }
}

This policy denies deleting or modifying any workflow tagged environment: production. It has no effect on workflows without that tag.

Common ABAC Patterns

Multiple Tag Conditions

When a policy specifies multiple tags, all tags must match (AND logic):

{
  "effect": "Deny",
  "resource": "secret",
  "actions": ["reveal"],
  "conditions": {
    "tags": {
      "environment": "production",
      "sensitivity": "high"
    }
  }
}

This denies decrypting (revealing) vault values that are tagged as both production and high sensitivity. Metadata access via secret:read is still allowed — only the value is hidden.

Best Practices

• Start with roles, add policies for exceptions. Roles handle the common case; policies handle edge cases.
• Use Deny sparingly. Broad Deny policies can be hard to debug. Prefer narrow, targeted denies.
• Tag consistently. Establish a tagging convention (e.g., always use environment, department, sensitivity) and enforce it across your organization.
• Test with Effective Permissions. After creating policies, check a user's effective permissions to verify the result matches your intent.
• Document your policies. Use the policy description field to explain why a policy exists, not just what it does.