Skip to main content

What's supported by Harness Platform

These are the supported Harness Platform features and integrations you can use for deploying and verifying your apps.

For supported platforms and technologies by module, go to the module documentation:

For supported platforms and technologies for SMP, go to What's supported in Self-Managed Enterprise Edition.

Authentication

The following table lists the supported Authentication features and various ways to authenticate users. Users in Administrator groups can use Authentication Settings to restrict access to an organization's Harness account. The options you choose apply to all of your account's users.

For more information, go to Authentication overview.

SSO TypeSSO ProvidersAuthentication SupportedAuthorization (Group Linking) SupportedSCIM Provisioning
SAML 2.0OktaYesYesYes
Microsoft Entra IDYesYesYes
OthersYesYesNo
OneLoginYesYesYes
OAuth 2.0GithubYesNoN/A
GitLabYesNoN/A
BitbucketYesNoN/A
GoogleYesNoN/A
AzureYesNoN/A
LinkedInYesNoN/A
LDAP (Delegate connectivity needed)Active DirectoryComing soonComing soonN/A
Open LDAPComing soonComing soonN/A
Oracle LDAPComing soonComing soonN/A

Delegates

Harness packages and distributes delegates on different types of images. Delegate images are identified by the delegate name. Image types are distinguished by tag.

Delegate-Legacy End of Support (EOS) notice

This is an End of Support (EOS) notice for the Delegate-Legacy image type. This image type reached End of Support (EOS) as of January 31, 2024.

End of Support means the following:

  • Harness Support will no longer accept support requests for the Delegate-Legacy image type in both Harness FirstGen and Harness NextGen (including Harness Self-Managed Enterprise Edition (SMP)).
  • Security fixes will still be addressed.
  • Product defects will not be addressed.

Follow the below steps to upgrade Delegate-Legacy to Delegate image

  • Download new yaml from Harness by keeping the same name as the previous delegate
  • Check if the existing delegate has any tags/selector, if yes then add them in DELEGATE_TAGS
  • Compare the permissions given to the legacy delegate in their yaml and give the same permissions to new delegates
  • Check if custom image is used, if yes then build a new image with immutable delegate as base image and override the account setting to point to that image
  • Ensure that auto upgrade is enabled for Kubernetes delegates
  • Our delegate yaml ships with default HPA of min and max replicas to be 1, adjust the desired number of replicas in HPA
  • Deploy the new yaml and see new replicas coming under the same delegate
  • Scale down the old stateful set and verify that everything is correct
Image typeImage tagImage description
DELEGATEyy.mm.xxxxxThe release year, month, and version in dot-separated format. Supported on both NextGen and FirstGen Harness Platform.
DELEGATE-MINIMALyy.mm.xxxxx.minimalThe minimal tag is appended to the release year, month, and version in dot-separated format. Supported on both NextGen and FirstGen Harness Platform.
DELEGATE-LEGACYlatestDelegate that auto upgrades with no flexibility to turn off auto upgrade (DEPRECATED)

For more information about delegates, go to:

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.

Kubernetes Deployments

For Kubernetes deployments, the following SDKs/tools are certified.

Manifest TypeRequired Tool/SDKCertified Version
Kuberneteskubectlv1.28.7
go-templatev0.4.1
Helmkubectlv1.27.0
helmv3.11.0
Helm (chart is stored in GCS or S3)kubectlv1.27.0
helmv3.11
chartmuseumv0.8.2 and v0.12.0
Kustomizekubectlv1.27.0
kustomizev4.5.4
OpenShiftkubectlv1.27.0
ocv4

Native Helm deployments

For Native Helm deployments (Helm chart manifest), the following SDKs/tools are certified:

  • helm v3.11
  • kubectl v.1.27.0

kubectl is required if Kubernetes version is 1.16 or later.

Install a delegate with custom SDK and 3rd-party tool binaries

To support customization, Harness provides a Harness Delegate image that does not include any third-party SDK binaries. We call this image the No Tools Image.

Using the No Tools Image and Delegate YAML, you can install the specific SDK versions you want. You install software on the Delegate using the INIT_SCRIPT environment variable in the Delegate YAML.

For steps on using the No Tools Delegate image and installing specific SDK versions, go to Install a Delegate with 3rd Party Tool Custom Binaries.

Git Experience

Harness Git Experience allows you to store your resource configurations, such as pipelines and input sets, in Git.

Supported Git providers for Harness Git Sync include:

  • GitHub
  • Bitbucket Cloud
  • Bitbucket Server
  • Azure Repos
  • GitLab

You can save the following Harness resources (entities) in Git using Harness Git Experience:

  • Pipelines
  • Input sets
  • Templates
  • Services
  • Environments
  • Infrastructure Definitions
info

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.

Harness Platform supports notifications for the following notification methods and collaboration tools:

Harness supports approvals for these collaboration tools:

  • Jira: Supports on-premise version < 9.0. For Jira on-premise >= 9.0 version support, enable the feature flag, SPG_USE_NEW_METADATA.
  • ServiceNow: Supports Utah version and earlier.

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

Open Source Software (OSS) components

For a list of the open source libraries and third-party software Harness uses, download the Harness Open Source Software (OSS) components PDF.

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.

  • Manage users: A Harness user is an individual with a unique email registered with Harness. Users can be associated with multiple accounts and user groups.

  • Manage roles: Roles are an RBAC component that contain a specific set of permissions that define what actions can be taken on Harness resources, such as viewing, creating, editing, or deleting. When you assign a role to a user, user group, or service account, the permissions defined in the role are automatically granted to the intended target.

    Harness includes some built-in roles, and you can also create your own custom roles to provide fine-grained access control.

  • Manage resource groups: Resource groups are an RBAC component that determine which objects a user or service account can access. Objects are any Harness resource, including projects, pipelines, connectors, secrets, delegates, environments, users, and more. When you assign resource groups to a user, user group, or service account, the access defined in the resource group is granted to the target user, group, or service account.

    Harness includes some built-in resource groups, and you can create custom resource groups, to provide fine-grained access control.

  • Manage user groups: User groups contain multiple Harness users. You assign roles and resource groups to user groups. The permissions and access granted by the assigned roles and resource groups are applied to all group members.

    You can also assign roles and resource groups to individual users that are not in a group. However, user groups help keep your RBAC organized and make it easier to manage permissions and access. Instead of modifying each user individually, you can edit the permissions and access for the entire group at once.

    Harness includes some built-in user groups, and you can create user groups manually, through inheritance, or through automated provisioning. You can create user groups at all scopes.

Using RBAC helps you:

  • Ensure that users can only access the information and resources necessary to perform their tasks. This reduces the risk of security breaches and unauthorized access to sensitive data.

  • Create systematic, repeatable permissions assignments. RBAC saves time and increases efficiency for administrators who otherwise have to manage access for individual user accounts. You can quickly add and change roles, as well as implement them across APIs.

  • Increase accountability by clearly defining who has access to which resources and information. This makes it easier to track and audit user activities, helping to identify and prevent misuse or abuse of access privileges.

  • Comply more effectively with regulatory and statutory requirements for confidentiality and privacy. It helps you enforce privacy and data protection policies.

  • Provision users and groups with SCIM - System for Cross-Domain Identity Management (SCIM) is an open standard protocol for automated user provisioning. In Harness, automated provisioning involves creating users and user groups, assigning users to groups, and managing some user attributes (such as names and email addresses). In addition to creating users and groups, automated provisioning also edits and removes users and user groups as and when required.

  • Use just-in-time (JIT) user provisioning: Automated provisioning eliminates repetitive tasks related to manual provisioning and simplifies user management.

    JIT provisioning in Harness lets you provision users automatically when they first sign-in to Harness through SAML SSO. Harness supports JIT provisioning only for new users logging in through an IdP, such as Okta.

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 resources depends on the level of control and visibility you require. For example, if you create a connector at the account scope, it is available to all organizations and projects within the account. However, if you create a connector at the organization scope, it is only available to that organization and any projects under that organization. It is not available at the account scope or to other organizations. This lets you control access to your resources more effectively and prevent unauthorized access.

To learn about organizations and projects, go to Create organizations and projects.

Resources across scopes

The following table lists some resources and their availability at various scopes in Harness:

ResourcesAccountOrgProject
PipelineNoNoYes
ServicesYesYesYes
EnvironmentsYesYesYes
Git ManagementNoNoYes
ConnectorsYesYesYes
SecretsYesYesYes
SMTP ConfigurationYesNoNo
TemplatesYesYesYes
Audit TrailYesYesNo
DelegatesYesYesYes
GovernanceYesYesYes

Secrets management

Harness includes a built-in Secret Management feature that enables you to store encrypted secrets, such as access keys, and use them in your Harness connectors and pipelines.

In addition to the built-in Secret Manager, Harness Platform supports the cloud platform secrets management services in the following table.

Provider NameKey Encryption SupportEncrypted Data Stored with HarnessSupport for Referencing Existing Secrets
AWS KMSYesYesNo
AWS Secret ManagerYesNoYes
Hashicorp VaultYesNoYes
Azure Key VaultYesNoYes
Google KMSYesYesNo

For more information, go to Harness 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 includes native TUF support via the following:

  • Deployment templates: Deployment Templates use shell scripts to connect to target platforms, obtain target host information, and execute deployment steps.
    • Deployment Templates can obtain the required metadata for native TUF support, and generate and validate signatures in the software lifecycle.
  • OCI image registry support:
  • Enforce the rotation of secrets and key management practices:
  • Continuous Verification: TUF recommends the verification of deployments akin to Harness Continuous Verification.

Active Platform feature flags

Some Harness Platform features are released behind feature flags to get feedback from specific customers before releasing the features to the general audience. Feature development statuses are categorized as Beta, GA, or Limited GA.

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

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

FlagDescription
PL_NO_EMAIL_FOR_SAML_ACCOUNT_INVITESWhen activated, it prevents sending email invitations to users of accounts using SSO for authentication during onboarding.
PL_LDAP_PARALLEL_GROUP_SYNCEnable 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_STANDARDSEnabling 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_SMEnabling this Feature Flag will let you use delegate credentials to access the Google Cloud Platform Secret Manager.
PL_DELEGATE_TASK_CAPACITY_CHECKWhen enabled, account tasks will be broadcasted until timeout. The default behavior is to broadcast tasks up to 3 times to delegates.
PL_FAVORITESAllows you to set the frequently accessed projects and connectors as favorites. For more information, go to Set favorites.
PL_ALLOW_TO_SET_PUBLIC_ACCESSAllows 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_GCP_OIDC_AUTHENTICATIONEnabling this feature flag allows GCP connectors using OpenID Connect (OIDC) to let Harness communicate directly with GCP through OIDC. For more information, go to Google Cloud Platform (GCP) connector settings reference.
PL_HIDE_ACCOUNT_LEVEL_MANAGED_ROLE, PL_HIDE_ORGANIZATION_LEVEL_MANAGED_ROLE, PL_HIDE_PROJECT_LEVEL_MANAGED_ROLEThis 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