For the complete documentation index, see llms.txt. This page is also available as Markdown.

Role-based access control (RBAC) in pipelines, templates, and secrets

Configure granular create and edit permissions for pipelines, templates, and secrets using split permission controls in Harness.

Harness provides granular role-based access control (RBAC) for pipelines, templates, and secrets. You can manage create and edit permissions independently for these resources, which gives you fine-grained control over who creates new resources and who modifies existing ones.

When you split the create and edit permissions, you can assign roles that allow users to create pipelines or secrets without granting them edit access to existing resources, or vice versa. This capability supports compliance requirements and provides better alignment with the principle of least privilege.

For more fine-grained control over access to connectors and environments, you can use Attribute-Based Access Control (ABAC) as an extension of RBAC on your resource groups. ABAC provides highly refined control by using rules to restrict access based on combinations of attributes, such as connector and environment type.


What you will learn in this topic

By the end of this topic, you will be able to:


Before you begin

Before you configure split permissions for pipelines, templates, or secrets, ensure you have the following:

  • Account administrator permissions: Account administrator access in Harness to configure roles and permissions. Go to RBAC in Harness to review roles and permissions.

  • Harness Support contact: Access to Harness Support to request feature flag enablement. Split permissions do not take effect until Harness Support enables the flags for your account.

  • Automation inventory: A list of all Terraform scripts, API integrations, and automation workflows that create or edit pipelines, templates, or secrets. These scripts must include explicit create permissions after the feature flags are enabled.


Split the create and edit permissions

Splitting the create and edit permissions decouples resource creation from resource modification, so you can grant one permission without the other.

  • Create permission: Allows users to create new pipelines, templates, or secrets.

  • Edit permission: Allows users to modify existing pipelines, templates, or secrets.

Create and edit are mutually exclusive grants. Users must be explicitly granted both permissions if they need to perform both actions, so a user with only edit cannot create a new resource, and a user with only create cannot modify an existing one.


Feature flags for split permissions

Each resource type is rolled out in two controlled phases, and the flags must be enabled in order. The migration flag adds the create permission to every role that already has edit, so no user loses access during the transition. The enforcement flag switches access checks over to the split permissions and shows Create and Edit as separate checkboxes in the UI.

Resource type
Migration flag
Enforcement flag

Pipelines and templates

PIPE_CREATE_EDIT_PERMISSION_SPLIT_MIGRATION

PIPE_CREATE_EDIT_PERMISSION_SPLIT

Secrets

PL_SECRET_CREATE_EDIT_PERMISSION_SPLIT_MIGRATION

PL_SECRET_CREATE_EDIT_PERMISSION_SPLIT_ENFORCE

Pipelines and templates share a single pair of flags, so enabling them splits the permissions for both resource types at the same time. Secrets use a separate pair of flags, which means you can adopt the split for secrets independently.

Currently, this feature is behind the feature flags listed above. Contact Harness Support to enable it. Onboarding is gated by customer approval per account.


Permissions reference

Select a tab to review the permissions for each resource type and how the create and edit grants change with the feature flags.

The following permissions are always available:

  • core_pipeline_view: Permission to view pipelines.

  • core_pipeline_execute: Permission to execute a pipeline.

  • core_pipeline_abort: Permission to abort an execution.

  • core_pipeline_delete: Permission to delete a pipeline.

Create and edit permissions depend on feature flag status:

  • With feature flags enabled: core_pipeline_create creates a pipeline, and core_pipeline_edit edits a pipeline.

  • Without feature flags: core_pipeline_edit is a combined permission to create and edit pipelines.

The following permissions are always available:

  • core_template_view: Permission to view a template.

  • core_template_copy: Permission to copy a template.

  • core_template_delete: Permission to delete a template.

  • core_template_access: General access to the template resource.

Create and edit permissions depend on feature flag status:

  • With feature flags enabled: core_template_create creates a template, and core_template_edit edits a template.

  • Without feature flags: core_template_edit is a combined permission to create and edit templates.

The following permissions are always available:

  • core_secret_view: Permission to view a secret.

  • core_secret_delete: Permission to delete a secret.

  • core_secret_access: Permission to access secrets at runtime.

Create and edit permissions depend on feature flag status:

  • With feature flags enabled: core_secret_create creates a secret, and core_secret_edit edits a secret.

  • Without feature flags: core_secret_edit is a combined permission to create and edit secrets.


Step 1: Enable the feature flags

Enable the flags in order so that existing roles are migrated before access checks change. Contact Harness Support and request the flags for the resource types you want to split, as listed in Feature flags for split permissions.

  1. Request enablement of the migration flag.

  2. After migration completes, typically 24-48 hours, request enablement of the enforcement flag.

During the migration phase, Harness automatically adds the create permission to every role that already holds the matching edit permission. For example, roles with core_pipeline_edit receive core_pipeline_create, and roles with core_secret_edit receive core_secret_create. New and updated roles receive both permissions.


Step 2: Assign split permissions

After both feature flags are enabled, you assign create and edit permissions independently when you create or modify a role.

  1. In your Harness account, navigate to Account Settings > Access Control > Roles.

  2. Select an existing role, or click New Role to create a role.

  3. In the Permissions section, expand Pipelines, Templates, or Secrets.

  4. Select the checkboxes for the permissions you want to assign:

    • Select Create to allow users to create new resources.

    • Select Edit to allow users to modify existing resources.

    • Select both checkboxes if users need both permissions.

  5. Click Save.

Users assigned this role now hold the create or edit permissions you configured.


Step 3: Update automation scripts

If you use Terraform, APIs, or other automation tools to manage Harness resources, update your scripts to request the create permission explicitly. Without this update, your automation can only edit existing resources and cannot create new ones.

Before split permissions, a single permission covered both actions:

After split permissions, list create and edit explicitly:

Before split permissions, a single permission covered both actions:

After split permissions, list create and edit explicitly:

Before split permissions, a single permission covered both actions:

After split permissions, list create and edit explicitly:


Enforcement behavior

Before you enable the enforcement flag, review the following behavior because they change how existing roles and automations resolve access.

  • Create and edit are exclusive: Users must be explicitly assigned both permissions if they need to perform both actions. A user with only edit permission cannot create new resources.

  • Terraform and API scripts must be updated: Scripts must include core_pipeline_create, core_template_create, or core_secret_create explicitly to perform create operations.

  • Edit-only users cannot delete or execute: These actions are governed by separate permissions, such as core_pipeline_delete and core_pipeline_execute.

  • Migration is automatic: During the migration phase, create permissions are added to roles that already have edit. Migration is customer-controlled and enabled per account.


Last updated

Was this helpful?