Security hardening for Harness CI
Harness offers features that help you build securely with Harness CI. Combine these features with known industry best practices.
The information is targeted at Harness CI. It is not a comprehensive explanation of all security features and capabilities throughout all Harness products, such as Harness STO.
Access control
Harness RBAC helps you control access to your Harness account, organizations, and projects. For authentication, Harness supports SSO and 2FA log-in methods, as well as SAML authentication through various IDPs.
Branch protection and PR checks
Failed CI pipelines don't inherently block PR merges. Harness can send pipeline statuses to your PRs, but you must configure branch protections and checks (such as protection rules, CODEOWNERS, linting, and other checks or restrictions) in your source control provider.
SLSA
With Harness CI, you can use the Harness Software Supply Chain Assurance (SSCA) module to generate, manage, store, and enforce SBOM and SLSA Provenance.
You can also run scripts in Run steps to generate SBOM and SLSA Provenance, and then upload those artifacts.
Secrets
Store tokens, passwords, and other sensitive data as secrets and then use expressions to reference secrets in your pipelines. For example, you can use an expression as the value for a variable:
APP_STORE_PASSWORD=<+secrets.getValue("my_app_store_password_secret")>
When you use secrets and variables in your CI pipelines, it is important to understand how those secrets appear in build logs. For example, secrets in Run step output variables are exposed in logs. For information about secrets masking and sanitization, go to:
- Secrets in output, secrets sanitization
- Line breaks and shell-interpreted characters
- Secrets and log sanitization
For more information about managing secrets in Harness, go to:
- Secrets documentation
- Authenticate GCP secrets in scripts
- Override secrets in settings.xml at runtime
Tokens and keys
Harness APIs use Harness API keys and tokens to authenticate requests. Make sure to create tokens with the appropriate permission scopes. Tokens inherit permissions from the account used to create them. For more information, go to Manage API keys.
You can store tokens and keys from non-Harness providers as secrets in Harness. Harness provides information about required permissions for third-party tokens and keys when relevant, such as authentication credentials for Git connectors; however, this is limited to the permissions necessary for successful integration with Harness.
For information about creating keys/tokens for a specific provider or tool, refer to the documentation for that provider or tool.
Network security
For network security and private networking, Harness offers features such as:
OIDC
You can use OpenID Connect (OIDC) with Harness CI.
With Harness Cloud, you can leverage the OIDC connectivity mode in your GCP connectors. You can then use OIDC-enabled GCP connectors in GCP-related steps, such as the Build and Push to GAR step. You can also Configure OIDC with GCP WIF for builds on Harness Cloud.
Not all step types support GCP connectors. However, you might need to perform operations with OIDC in steps that don't support GCP connectors. For example, if you use a Run step to pull artifacts from GAR with OIDC, you need the OIDC token in the Run step to successfully pull the artifact. In these cases, you can use the GCP OIDC plugin to generate a GCP access token from an OIDC token.
OIDC is also available in other areas of Harness, such as in the platform-agnostic Kubernetes cluster connector and in other Harness modules.