Harness pipelines deploy to production with credentials held by delegates and secret managers, so the access model around delegates, secrets, roles and API tokens decides who can change what runs in your environments. This guide covers the customer side of securing the Harness Platform: how scopes, roles and resource groups grant access, which roles are privileged, how delegates connect and authenticate, where secrets are stored and decrypted, how service account tokens should be managed, how Policy as Code governs pipelines, and what the audit trail records. It is written for platform engineers, Harness account administrators and security reviewers. For controls that apply to any pipeline platform, see the CI/CD Security Guide.
This is an independent guide from NHI Mgmt Group, based on Harness's public documentation as of November 2026. It is not sponsored or reviewed by Harness. Product features change, so confirm settings against Harness's current documentation.
Key takeaways
- Scope everything to the lowest level. Harness grants flow down from Account to Organization to Project and are additive with no explicit deny, so narrow assignments are the only way to limit access.
- Give each delegate group its own token. All delegates share one default token in a new account; create tokens per environment, store them in a secret manager and revoke them when a delegate is retired.
- Keep secrets in your own secret manager. With an external manager, Harness stores only a reference; use the built in manager mainly for the credentials that unlock that external manager.
- Treat service account tokens as production credentials. Tokens carry the
sat.prefix and inherit the service account's role bindings; set an expiry rather than No Expiration and rotate. - Enforce pipeline rules with OPA. Policy sets with Error and Exit severity on On Save and On Run stop non compliant pipelines before they deploy.
How identity and access work in Harness
Harness RBAC has four parts: principals (users, user groups and service accounts), roles (sets of permissions), resource groups (which resources the roles apply to) and scopes. A role binding pairs a role and a resource group with a principal at a scope. The model is additive: a principal's access is the union of every binding it receives directly or through its user groups, and the docs state there is no explicit deny. An assignment reaches a resource only if it is made at the resource's scope or an ancestor and its resource group covers that scope, so a Project Admin binding does not reach an account level connector.
| Element | Options in the docs | Customer guidance |
|---|---|---|
| Scopes | Account, Organization, Project | Create resources at the lowest scope that works; put production in its own organization or project |
| Principals | Users, user groups, service accounts | Bind roles to user groups synced from your identity provider, not to individuals |
| Built in roles | Account Admin, Account Viewer, Organization Admin, Organization Viewer, Project Admin, Project Viewer, Pipeline Executor | Use custom roles for day to day work; reserve Admin roles for a small group |
| Resource groups | All Resources or Named Resources; built in groups such as All Project Level Resources | Use named resource groups for production connectors, secrets and environments |
| ABAC | Attribute based rules on resource groups for connectors and environments | Separate production environments from non production by attribute |
Authentication settings
Harness supports username and password, public OAuth providers (Azure, Bitbucket, GitLab and GitHub), SAML, including multiple identity providers, and LDAP. The authentication settings give account administrators several controls worth setting on day one:
- Enforce Two Factor Authentication: applies to every login, through SSO or username and password.
- Session timeouts: Session Inactivity Timeout defaults to 1440 minutes (one day) with a range of 30 to 4320; Absolute Session Timeout defaults to 0 (not set) with a maximum of 4320. We suggest a shorter inactivity timeout and an absolute timeout for privileged users.
- Password policy: enforce password strength, periodic expiry and a lockout policy if local passwords remain in use.
- Email domain allowlist: Only allow users with the following email domains restricts both SSO and password logins to your domains.
- Public OAuth: the docs say to disable public OAuth providers before enabling SAML; do so once SSO works so that every login goes through your identity provider.
See the SAML Security Guide for the identity provider side.
Admin roles and privileged access
Privilege in Harness comes from roles bound at high scopes and from permissions over the resources that hold credentials: delegates, secrets and connectors. The delegate permissions are Create/Edit, Delete and View, and downstream restrictions apply to pipelines (Execute), secrets (Access) and connectors (Access).
| Privilege | Why it matters | Control (ours where noted) |
|---|---|---|
| Account Admin | Manages authentication, service accounts, delegates and all child scopes | Two to four named people with phishing resistant MFA; a documented break glass account |
| Organization or Project Admin on production | Can change pipelines, connectors and secrets that deploy to production | Bind to a production admin group, review quarterly |
| Create/Edit Delegate | Required to create and manage delegate tokens | Platform team only |
| Secrets Access and Connector Access | Lets a pipeline or user use a credential | Named resource groups per environment |
| Service account management | Requires Account Admin or equivalent view, create or edit, manage and delete permissions | Limit to identity administrators; record an owner for each service account |
| Authentication Settings permissions | Controls IP allowlists and login policy | Account administrators only |
IP allowlists
Under ACCOUNT SETTINGS > Authentication > Allowlist, administrators can limit logins to listed IP addresses or CIDR blocks (IPv4 and IPv6), applying each range to UI or API traffic. Blocked requests receive HTTP 401. The allowlist does not apply to delegate connections, and SCIM calls, identity provider calls and certain admin API calls are exempt. Add your own address first and use the Test option, because the docs warn you can lock yourself out, and changes can take up to five minutes to apply.
Delegates
A delegate is a service you run in your own network or VPC that performs deployment and integration operations and connects your providers to Harness Manager. It makes an outbound HTTPS and secure WebSocket connection to Harness Manager; the WebSocket channel carries task notifications and heartbeats rather than task data. Harness recommends installing delegates behind your firewall, in the same VPC as the services you deploy.
| Delegate setting | Documented behaviour | Customer action |
|---|---|---|
| Scope | Account, Organization or Project | Install production delegates at the production project or organization scope |
| Tags and selectors | A name tag is added automatically; selecting tags restricts tasks to those delegates with no fallback | Pin production pipelines and connectors to production delegates with selectors |
| Delegate tokens | Encrypt delegate to Manager communication; one default token in a new account | Create a token per environment; revoke on retirement |
| Images | Non root harness/delegate:yy.mm.verno and a .minimal variant without client tools | Use the minimal image plus only the tools you need; scan custom images |
| Remote logging | By default sends logs to Google's Stackdriver Logging API; STACK_DRIVER_LOGGING_ENABLED=false disables it | Decide deliberately where delegate logs go, and forward local logs to your SIEM |
| Auto upgrade | Shown in the Delegates list | Keep auto upgrade on, or patch promptly to Harness's release cadence |
Delegate tokens in practice
Revoking a token immediately disconnects and stops every delegate using it, and only revoked tokens can be deleted. For Kubernetes delegates, the token is set as DELEGATE_TOKEN and UPGRADER_TOKEN in the delegate manifest. Harness documents creating tokens through the API (createDelegateToken), storing them in a secret manager and injecting them at deploy time, with a HashiCorp Vault agent injection example, and also documents delegate tokens as Kubernetes secrets. Rotation requires redeploying the delegate, so plan it as a rolling change: create the new token, redeploy one replica, confirm it connects, roll the rest, then revoke the old token. The secure delegates section also covers custom certificates, mTLS support, truststore overrides and running on a read only file system; adopt mTLS where your edition offers it. The delegate also needs Kubernetes or cloud permissions to deploy; review what the install manifest grants and scope the delegate's own service account and cloud role to the targets it serves. See the Kubernetes Service Account Token Guide.
Integrations, API tokens and service accounts
Secret managers
The built in Harness Secret Manager Google KMS uses envelope encryption: the encrypted secret and the encrypted data key are stored in the Harness database while the KMS holds the key. With a third party secret manager (HashiCorp Vault, Azure Key Vault, AWS Secrets Manager, AWS KMS, Google Cloud Secret Manager, Google KMS or a custom manager such as CyberArk Conjur), the manager stores the secret and Harness keeps only a reference. Harness's guidance is to use the built in manager only for the credentials of the corresponding secret manager, and not to store one manager's credentials in another.
- Who decrypts: with Connect Through Delegate, the delegate in your network decrypts secrets; with Connect Through Manager, Harness Manager does. Choose delegate based connections for production secret managers so decryption stays inside your network.
- Log sanitisation: Harness masks text secrets and JWTs in deployment logs and script output with asterisks, and masks Kubernetes Secret values in deployment logs. It matches exact values only, so a script that transforms a secret can print it, and file secrets are not masked. Avoid transforming secrets in scripts and quote expressions as the docs describe.
- Secret cache: encrypted data and metadata are cached for 30 minutes, so a rotated value may take up to that long to apply for some manager types. Overlap old and new credentials during rotation.
- Key rotation caveat: the docs state that removing an older key version from your KMS can make secrets encrypted with it inaccessible; retire old key versions only after re-encrypting.
API keys and tokens
| Token type | Created where | Permissions | Guidance |
|---|---|---|---|
| Personal access token | Account level, under My API Keys in the user profile | Same as the user | Use for personal scripting only; never in pipelines |
| Service account token | Any scope, on a service account's API key | The service account's role bindings | Use for automation; one service account per integration |
Each API key can hold several tokens. Expiry options are 30, 90 or 180 days, a custom date, or no expiration; Harness checks expiry every five minutes and records expiry events in the audit trail. The Rotate Token action issues a new value with a new expiry date. Tokens are shown once. Create role bindings for a service account before its API keys, give a project level integration an account level service account with project level bindings only when it truly needs account resources, and remember that deleting a service account invalidates all its keys and tokens. Our recommendation is 90 days or less for service account tokens and 30 days for personal tokens. See the API Key Management Guide.
Pipeline governance with Policy as Code
Harness Policy as Code uses Open Policy Agent with policies written in Rego. A policy is enforced only when it is added to a policy set, which binds policies to an entity type and an event, each with a severity: Warn and Continue or Error and Exit. Pipelines can be evaluated On Save, On Run (after preflight checks) and, behind a feature flag, On Step Start; templates, services, feature flags, repositories and custom entities have their own events. Policies and sets can live at Account, Organization or Project scope and apply downwards. Each evaluation receives the entity's JSON plus user metadata such as roles and groups. Harness SaaS evaluation does not run the Rego built ins http.send and net.lookup_ip_addr, so keep policies self contained.
- Start with warnings: publish policy sets at account scope with Warn and Continue and use blast radius analysis to see which pipelines would fail.
- Enforce on save and run: switch to Error and Exit for rules such as approval steps before production stages, delegate selectors on production steps, allowed connectors and registries, and no inline secrets.
- Protect the policies: limit who can edit governance policies to the security or platform governance group, and review policy changes through Git where possible.
- Roll back safely: if an enforced policy blocks critical work, return the policy set to Warn and Continue rather than deleting it, fix the rule and re-enforce.
See the Policy-as-Code for Authorisation Guide for writing maintainable policies.
Logging and detection
The Harness audit trail records who did what, when and where (time, user, action, resource, organization, project, module and a YAML diff), cannot be altered and is kept for up to two years. It is viewable at account and organization scope. Pipeline start and end events are not captured by default; turn on Enable Pipeline Execution Audit Events in account settings. Use audit log streaming to keep records beyond two years in your SIEM.
| Event | Why it matters |
|---|---|
| Role binding, user group or service account changes | Privilege escalation or persistence |
| Delegate token created or revoked; new delegate registered | An unknown delegate could receive production tasks |
| Secret manager or connector edits | Credential redirection or exposure |
| Policy set changed to warn or disabled | Governance bypass before a deployment |
| Authentication settings and allowlist changes | Changes to login controls outside a change window |
| API token created with no expiration | Long lived non-human credential |
Metrics to track (our suggestions): number of Account Admins; share of service account tokens with an expiry (target 100 percent); delegate tokens per environment and the age of each; production pipelines covered by an enforced policy set; policy warnings per week; time to revoke access for leavers.
Hardening baseline
- Identity first: SAML or LDAP SSO, two factor enforcement, email domain allowlist, public OAuth off once SSO works, sensible session timeouts.
- Structure: production in its own organization or project; user groups from your identity provider; custom roles and named resource groups.
- Delegates: per environment tokens held in a secret manager, selectors on production work, minimal images, auto upgrade, local logs forwarded.
- Secrets: external secret manager with delegate based decryption; built in manager only for bootstrap credentials.
- Tokens: service accounts per integration, expiring tokens, rotation on a schedule, personal tokens out of pipelines.
- Governance and audit: OPA policy sets from warn to enforce, pipeline execution audit events on, audit streaming to the SIEM, and Harness security updates and delegate upgrades applied promptly.
Decision guidance
- Harness SaaS with cloud targets: delegates in each target VPC, IP allowlist for UI and API, OIDC based secret manager connections where offered.
- Self-Managed Enterprise Edition: the docs note it uses a random key secrets store as the Harness Secret Manager and that secrets cannot be migrated from it, so configure your external secret manager before creating secrets.
- Small team: one organization with separate projects per environment and two Account Admins is enough; add ABAC as environments grow.
Common misconfigurations
- One default delegate token everywhere: revoking it stops every delegate, and a leak affects all environments.
- Broad roles at account scope: because grants are additive and flow down, one wide account binding outweighs careful project bindings.
- Service account tokens with No Expiration: automation credentials outlive the projects and people that created them.
- Production secrets in the built in manager: keeps production credentials outside your own rotation and access controls.
- No delegate selectors on production steps: tasks can run on any eligible delegate, including non production ones.
- Policies left in warn mode: warnings are visible but nothing stops a non compliant deployment.
Framework mapping
| Control area | NIST SP 800-53 Rev 5 | MITRE ATT&CK risk addressed | OWASP CI/CD Top 10 |
|---|---|---|---|
| Scoped roles, resource groups, ABAC | AC-6 Least Privilege | T1098 Account Manipulation | CICD-SEC-2 Inadequate Identity and Access Management |
| Delegate tokens, service account tokens, secret managers | IA-5 Authenticator Management | T1528 Steal Application Access Token, T1552.001 Credentials In Files | CICD-SEC-6 Insufficient Credential Hygiene |
| OPA policy sets on save and run | CM-3 Configuration Change Control | T1195.002 Compromise Software Supply Chain | CICD-SEC-1 Insufficient Flow Control Mechanisms |
| Delegate selectors and minimal images | CM-7 Least Functionality | T1078.004 Cloud Accounts | CICD-SEC-5 Insufficient PBAC |
| Audit trail and streaming | AU-2 Event Logging | T1098 Account Manipulation | CICD-SEC-10 Insufficient Logging and Visibility |
Practitioner checklist
- Enforce SSO and two factor authentication, restrict email domains and set session timeouts.
- Keep Account Admin to a few named people and bind roles to identity provider groups.
- Use named resource groups for production secrets, connectors and environments.
- Replace the default delegate token with per environment tokens stored in a secret manager.
- Pin production steps and connectors to production delegates with selectors.
- Use an external secret manager with Connect Through Delegate for production.
- Issue automation tokens from service accounts with an expiry, and rotate them.
- Configure IP allowlists for UI and API after testing your own address.
- Publish OPA policy sets, then move them from Warn and Continue to Error and Exit.
- Enable pipeline execution audit events and stream the audit trail to your SIEM.
Standards and references
- Harness: Delegate Overview
- Harness: Secure Delegates with Tokens
- Harness: RBAC in Harness
- Harness: Harness Secret Manager Overview
- Harness: Add and Manage API Keys
- Harness: Policy as Code Overview
- Harness: Audit Trail
- OWASP: Top 10 CI/CD Security Risks
Related NHI Mgmt Group resources: CI/CD Security Guide, CI/CD Pipeline Identity Security Guide, Secrets Management Guide, API Key Management Guide, Policy-as-Code for Authorisation Guide.