Harness CI/CD Security Features

Harness positions itself as a modern CI/CD platform with security built in rather than bolted on. Unlike Jenkins where every security feature requires a plugin, Harness ships with governance policies, secret management integration, and role-based access controls as core platform capabilities. But built-in does not mean properly configured. Most Harness deployments leave significant security value on the table.

This guide covers the security features Harness provides and how to configure them for real protection.

Platform Architecture and Security Implications

Harness operates as a SaaS platform (with a self-hosted option) that connects to your infrastructure through a delegate — a lightweight agent running in your environment. Understanding this architecture is critical for security:

• Harness Manager: SaaS control plane. Stores pipeline definitions, secrets (encrypted), and audit data.
• Delegates: Run in your VPCs, Kubernetes clusters, or on-premise infrastructure. Execute pipeline steps against your resources.
• Connectors: Configured connections to Git repos, cloud providers, registries, and other services.

The delegate is the trust boundary. It runs in your environment and has access to whatever resources its host can reach. Securing delegates is securing your deployment infrastructure.

Delegate Security

Delegates are your highest-priority security target:

Network Isolation

Run delegates in dedicated subnets with restricted outbound access:

• HTTPS to the Harness Manager SaaS endpoint.
• HTTPS/SSH to your Git repositories.
• HTTPS to your artifact registries and cloud provider APIs.
• Nothing else.

Dedicated Delegate Groups

Create separate delegate groups for different trust levels:

# Production delegate - runs only production deployments
delegateGroup:
  name: production-delegates
  tags:
    - production
    - restricted

# Development delegate - broader access for dev workflows  
delegateGroup:
  name: dev-delegates
  tags:
    - development

Use pipeline-level delegate selectors to ensure production pipelines only run on production delegates, and development pipelines cannot target production infrastructure.

Ephemeral Delegates

Use Kubernetes-based delegates that spin up for each task and terminate afterward. This prevents state accumulation and limits the window for compromise.

OPA Governance Policies

Harness integrates Open Policy Agent (OPA) for policy-as-code governance. This is one of its strongest security features.

# Require approval stage before production deployment
package pipeline

deny[msg] {
    input.pipeline.stages[i].stage.type == "Deployment"
    input.pipeline.stages[i].stage.spec.environment.type == "Production"
    not has_approval_before(i)
    msg := "Production deployments require an approval stage"
}

has_approval_before(deploy_index) {
    input.pipeline.stages[j].stage.type == "Approval"
    j < deploy_index
}

# Enforce specific scanning steps
package pipeline

deny[msg] {
    input.pipeline.stages[_].stage.type == "CI"
    not has_security_scan
    msg := "CI stages must include security scanning"
}

has_security_scan {
    input.pipeline.stages[_].stage.spec.execution.steps[_].step.type == "Security"
}

Policies evaluate at pipeline save time and at runtime. A pipeline that violates governance policies cannot be saved or executed. This gives your security team programmatic control over deployment standards without being a bottleneck.

Create policies for:

• Mandatory security scanning stages.
• Required approval gates for production.
• Restricted deployment windows.
• Prohibited container registries or base images.
• Required notification steps.

Secret Management

Harness integrates with external secret managers rather than forcing you to use its built-in storage:

• HashiCorp Vault
• AWS Secrets Manager
• Azure Key Vault
• GCP Secret Manager

connector:
  name: vault-production
  type: Vault
  spec:
    vaultUrl: https://vault.example.com
    authToken: ${vault_token}
    secretEngineManifestPath: secret/data/production
    renewalIntervalMinutes: 60

Best practices:

• Use an external secret manager. Harness's built-in secret storage is encrypted, but external managers provide better audit trails, rotation, and access controls.
• Create separate secret manager connectors per environment.
• Restrict which pipelines can access which secret manager connectors using Harness RBAC.
• Enable secret rotation and ensure pipelines pick up rotated values without manual intervention.

RBAC Configuration

Harness RBAC operates at multiple levels: account, organization, and project.

# Example: Developer role at project level
role:
  name: Project Developer
  permissions:
    - resourceType: PIPELINE
      actions: [view, execute]
    - resourceType: CONNECTOR
      actions: [view]
    - resourceType: SECRET
      actions: [view]  # Can reference but not read values
    - resourceType: ENVIRONMENT
      actions: [view]
      filter:
        environmentType: PreProduction

Key RBAC principles:

• Separate admin, deploy, and view roles: Not everyone who can view a pipeline should execute it.
• Environment-level restrictions: Developers can deploy to dev and staging but not production.
• Project-level scoping: Teams only see their own projects.
• Service account management: Create dedicated service accounts for automated triggers with minimal permissions.

Pipeline Guardrails

Beyond OPA policies, Harness provides pipeline-level guardrails:

Freeze Windows

Block deployments during sensitive periods:

freezeWindow:
  name: Holiday Freeze
  schedule:
    startTime: "2023-12-20T00:00:00Z"
    endTime: "2024-01-03T00:00:00Z"
  excludeProjects:
    - emergency-fixes

Input Sets and Overlays

Use input sets to predefine allowed values for pipeline parameters, preventing operators from entering arbitrary values at runtime.

Failure Strategies

Configure automatic rollback on security check failures:

failureStrategies:
  - onFailure:
      errors:
        - PolicyEvaluationFailure
      action:
        type: Abort
  - onFailure:
      errors:
        - Verification
      action:
        type: StageRollback

Continuous Verification

Harness Continuous Verification monitors deployments using APM and logging data. Configure it as a security control:

• Set up verification steps that check for anomalous error rates after deployment.
• Use custom metrics to detect security-relevant changes (authentication failures, authorization errors, unexpected API calls).
• Configure automatic rollback if verification detects anomalies.

Audit Trail

Harness maintains a comprehensive audit trail. Export it to your SIEM and create alerts for:

• Pipeline configuration changes.
• RBAC modifications.
• New connector creation (especially to production infrastructure).
• Secret access patterns.
• Governance policy overrides.
• Delegate registration and deregistration.

How Safeguard.sh Helps

Safeguard.sh complements Harness's built-in governance by providing security visibility that extends beyond the CI/CD pipeline. While Harness enforces policies at pipeline execution time, Safeguard.sh continuously monitors the artifacts Harness deploys — tracking SBOMs, vulnerability status, and compliance posture across every environment. It correlates Harness deployment events with runtime security data, giving your team a unified view of what was deployed, whether it met security standards, and what new risks have emerged since deployment.