Ctrlk
Sign UpGet a DemoContact Us
For the complete documentation index, see llms.txt. This page is also available as Markdown.

What's Supported by Harness Platform

Technologies supported by Harness Platform

This topic provides an overview of the technologies, features, and integrations supported by Harness to deploy and verify applications.

For more information about What's Supported for other Harness modules, see their respective documentation below:

To see supported technologies and features for the Self-Managed Enterprise Edition, refer to the following resources:

Authentication

Authentication is the process of verifying a user’s identity before granting access to an account. In Harness, administrators can configure authentication settings to control how users sign in and manage access to the organization’s account.

For additional details, refer to the Authentication Overview.

SSO Type
SSO Providers
Authentication Supported
Authorization Supported (Group Linking)
SCIM Provisioning

SAML 2.0

Okta

Yes

Yes

Yes

Microsoft Entra ID

Yes

Yes

Yes

Others

Yes

Yes

No

OneLogin

Yes

Yes

Yes

OAuth 2.0

Github

Yes

No

N/A

GitLab

Yes

No

N/A

Bitbucket

Yes

No

N/A

Google

Yes

No

N/A

Azure

Yes

No

N/A

LinkedIn

Yes

No

N/A

LDAP (Delegate connectivity needed)

Active Directory

Coming soon

Coming soon

N/A

Open LDAP

Coming soon

Coming soon

N/A

Oracle LDAP

Coming soon

Coming soon

N/A

Delegates

The Delegate is a lightweight worker process packaged and distributed by Harness using different image types. Each Delegate image is identified by a delegate name, and the image type is specified using a tag.

Image Type
Image Tag
Image Description

DELEGATE

yy.mm.xxxxx

The release year, month, and version in dot-separated format. Supported on both NextGen and FirstGen Harness Platform.

DELEGATE-MINIMAL

yy.mm.xxxxx.minimal

The minimal tag is appended to the release year, month, and version in dot-separated format. Supported on both NextGen and FirstGen Harness Platform.

DELEGATE FIPS

yy.mm.xxxxx-fips

The release year, month, and version in dot-separated format.

FIPS (Federal Information Processing Standard) compliant images compatible only with FIPS SMP and is not supported for SaaS environments.

DELEGATE FIPS-MINIMAL

yy.mm.xxxxx.minimal-fips

The minimal-fips tag is appended to the release year, month, and version in dot-separated format.

FIPS (Federal Information Processing Standard) compliant images compatible only with FIPS SMP and is not supported for SaaS environments.

DELEGATE-LEGACY

latest

Delegate that auto upgrades with no flexibility to turn off auto upgrade (DEPRECATED)

SDKs installed with Harness Delegate

The Harness Delegate includes binaries for the SDKs that are required for deployments with Harness-supported integrations. These include binaries for Helm, ChartMuseum, kubectl, Kustomize, and so on.

  1. Kubernetes Deployments: The following SDKs and tools are certified for Kubernetes deployments.

    Manifest Type
    Required Tool/SDK
    Certified Version

    Kubernetes

    kubectl

    v1.29.2

    go-template

    v0.4.1

    Helm

    kubectl

    v1.27.0

    helm

    v3.11.0

    Helm (chart is stored in GCS or S3)

    kubectl

    v1.27.0

    helm

    v3.11

    chartmuseum

    v0.8.2 and v0.12.0

    Kustomize

    kubectl

    v1.27.0

    kustomize

    v5.0.4

    OpenShift

    kubectl

    v1.27.0

    oc

    v4

  2. Native Helm deployments: The following SDKs and tools are certified for native helm deployments

    • helm v3.11

    • kubectl v.1.27.0

    kubectl is required if Kubernetes version is 1.16 or later.

  3. Install a delegate with custom SDK and third party tool binaries

    To support customization, Harness provides a Delegate image that excludes all third-party SDK binaries. This image is referred to as the No Tools Image. Using the No Tools Image along with the Delegate YAML, you can install the required SDK versions using an initialization script defined in the INIT_SCRIPT environment variable in the Delegate YAML.

    To use the No Tools Delegate image and install specific SDK versions, see Install a Delegate with third party custom tool binaries.

For additional information about the Delegate, refer to the following documentation:

Git Experience

Harness Git Experience allows you to store your resource configurations, such as pipelines and input sets, in Git. You can use Git as the single source of truth and modify your configurations using your Git credentials.

Supported Git providers for Harness Git Sync include:

  • GitHub

  • Bitbucket Cloud

  • Bitbucket Server

  • Azure Repos

  • GitLab

Supported Harness resources (entities) in Git using Harness Git Experience:

  • Pipelines

  • Input sets

  • Templates

  • Services

  • Environments

  • Infrastructure Definitions

Artifact Source templates are not supported with Git Experience.

Notifications and collaboration

Notifications are used to alert your team of new, resurfaced, or critical events. With notifications, you can ensure your team is aware of important events that require action.

Supported notifications methods and collaboration tools:

Harness supports approvals for these collaboration tools:

  • Jira: Supports on-premise version < 9.0.

    To enable support for Jira on-premise version 9.0 or later, turn on the feature flag SPG_USE_NEW_METADATA.

  • ServiceNow: Supports Utah version and earlier.

For other providers, you can use custom approvals or manual approvals

Software Bill of Materials (SBOM) and Open Source Software (OSS) components

The Harness Software Bill of Materials (SBOM) provides detailed information about all the packages used to build Harness software. SBOMs are available in CycloneDX format and include key details for each package, such as:

  • Name: The package or component name.

  • Version: The specific version used.

  • Licenses: Licensing information for the package.

  • Supplier: The vendor or source of the package.

  • Relationships: Dependencies and connections between packages.

This information helps organizations understand the composition of Harness software, assess licensing, and manage security or compliance requirements effectively.

For detailed information about the SBOM/OSS component list used by Harness, visit the Harness Trust Center.

Role-based access control (RBAC)

Role-based access control (RBAC) lets you control who can access your resources and what actions they can perform on the resources. To do this, a Harness account administrator assigns resource-related permissions to members of user groups.

Harness supports managing Role-Based Access Control (RBAC) through SCIM (System for Cross-Domain Identity Management). This allows you to automate the provisioning and de-provisioning of users and groups from your identity provider, ensuring that access permissions stay up-to-date and consistent across your organization.

For more information, see Role-Based Access Control (RBAC) in Harness .

Resource hierarchy

The Harness Platform is structured hierarchically with three levels of access: Account, Organization (Org), and Project. Each level can have its own set of permissions configured, allowing for delegation of responsibilities to various teams. This approach facilitates efficient organization and management of resources, enabling granular access control that is both scalable and easy to manage.

Scopes

  • Account is the highest level. It is your Harness account, and it encompasses all the resources within your Harness subscription.

  • Organization encompasses projects, resources, and users in a specific domain or business unit. This allows for the management of resources and permissions unique to an organization, separate from other areas of the account.

  • Project contains related resources, such as apps, pipelines, and environments. This allows for the management of resources and permissions specific to a particular project, separate from the larger org (business unit) and account.

The scope at which you create a resource determines its availability and visibility.

  • Account scope: Resources are available to all organizations and projects within the account.

  • Organization scope: Resources are available only to that organization and its projects, not to other organizations or the account as a whole.

Choosing the appropriate scope helps you control access and prevent unauthorized use. For more information, see Create organizations and projects.

Resources across scopes

The table below lists resources and their availability at different scopes in Harness:

Resources

Account

Org

Project

Pipeline

No

No

Yes

Services

Yes

Yes

Yes

Environments

Yes

Yes

Yes

Git Management

No

No

Yes

Connectors

Yes

Yes

Yes

Secrets

Yes

Yes

Yes

SMTP Configuration

Yes

No

No

Templates

Yes

Yes

Yes

Audit Trail

Yes

Yes

No

Delegates

Yes

Yes

Yes

Governance

Yes

Yes

Yes

Secrets management

Harness offers a built-in Secret Management feature for securely storing and using encrypted secrets. Additionally, the platform supports cloud provider secret management services, as shown in the table below.

Provider Name
Key Encryption Support
Encrypted Data Stored with Harness
Support for Referencing Existing Secrets

AWS KMS

Yes

Yes

No

AWS Secret Manager

Yes

No

Yes

Hashicorp Vault

Yes

No

Yes

Azure Key Vault

Yes

No

Yes

Google KMS

Yes

Yes

No

For more information, see Secrets Management overview.

Supported browsers

The following desktop browsers are supported:

  • Chrome: latest version

  • Firefox: latest version

  • Safari: latest version

  • All Chromium-based browsers.

Mobile browsers are not supported.

Supported screen resolution

Minimum supported screen resolution is 1440x900.

The Update Framework (TUF)

The Update Framework (TUF) is an open source specification for that provides instructions on how to organize, sign, and interact with metadata to secure package managers.

Harness provides native TUF (The Update Framework) support through the following capabilities:

  • Deployment Templates

    • Deployment Templates use shell scripts to connect to target platforms, gather host information, and execute deployment steps.

    • Deployment Templates can obtain the metadata required for TUF, and generate and validate signatures throughout the software lifecycle.

  • OCI Image Registry Support

  • Secrets and Key Management

    • Harness enforces token and key rotation as part of best practices for secrets management. See rotating API tokens.

  • Continuous Verification

Active Platform feature flags

Few Harness Platform features are released behind feature flags to gather feedback from specific customers before a general release. Feature development status is categorized as Beta, GA, or Limited GA.

To enable a feature flag in your Harness account, contact Harness Support.

The following table describes active feature flags relevant to Harness Platform.

Flag
Description

PL_NO_EMAIL_FOR_SAML_ACCOUNT_INVITES

When activated, it prevents sending email invitations to users of accounts using SSO for authentication during onboarding.

PL_LDAP_PARALLEL_GROUP_SYNC

Enable User Group sync operation to fetch data from the LDAP server in parallel. Only enable this if the LDAP server can handle the load.

PL_NEW_SCIM_STANDARDS

Enabling the PL_NEW_SCIM_STANDARDS feature flag ensures compliance with SCIM 2.0 standards by including the meta fields createdAt, lastUpdated, version, and resourceType in CRUD operation responses on users or user groups.

PL_USE_CREDENTIALS_FROM_DELEGATE_FOR_GCP_SM

Enabling this Feature Flag will let you use delegate credentials to access the Google Cloud Platform Secret Manager.

PL_DELEGATE_TASK_CAPACITY_CHECK

When enabled, account tasks will be broadcasted until timeout. The default behavior is to broadcast tasks up to 3 times to delegates.

PL_FAVORITES

Allows you to set the frequently accessed projects and connectors as favorites. For more information, go to Set favorites.

PL_ALLOW_TO_SET_PUBLIC_ACCESS

Allows pipeline executions marked for access to public view without authentication. You can share execution URLs, including console logs, without requiring users to sign in. For more information, go to Allow public access to pipeline executions.

PL_HIDE_ACCOUNT_LEVEL_MANAGED_ROLE, PL_HIDE_ORGANIZATION_LEVEL_MANAGED_ROLE, PL_HIDE_PROJECT_LEVEL_MANAGED_ROLE

This feature flag is used to hide managed roles at various levels: account level, organization level, and project level. Existing role bindings for managed roles will still exist for users, but new role bindings with managed roles won't be allowed when the feature flag is enabled. The managed roles won't show up in the list of roles available at the respective scopes. For more information, go to Manage Roles

PreviousGet Started
NextAuthentication

Last updated

Was this helpful?