What's supported by Harness Platform
This topic lists the supported Harness Platform features and integrations you can use for deploying and verifying your apps.
For a comprehensive list that includes all Harness modules, go to Supported platforms and technologies.
- Git Experience
- AuthN
- Accounts Orgs Projects
- Delegates
- Notifications
- Secrets Mgmt
- RBAC
- Self-Managed EE
Harness Git Experience allows you to store your resource configurations, such as pipelines and input sets, in Git.
Supported Git providers
The following section lists the support for Git providers for Harness Git Sync:
- GitHub
- Bitbucket Cloud
- Bitbucket Server
- Azure Repos
- GitLab
Supported Harness entities
You can save the following Harness resources in Git using Harness Git Experience:
- Pipelines
- Input sets
- Templates
- Services
- Environments
- Infrastructure Definitions
Artifact Source templates are not supported with Git Experience.
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 will apply to all of your account's users.
For more information, go to Authentication overview.
| SSO Type | SSO Providers | Authentication Supported | Authorization (Group Linking) Supported | 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 | |
| Yes | No | N/A | ||
| Azure | Yes | No | N/A | |
| 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 |
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 the resources that are available at various 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 | Yes |
| Delegates | Yes | Yes | Yes |
| Governance | Yes | Yes | Yes |
Harness packages and distributes delegates on different types of images. Delegate images are identified by the delegate name. Image types are distinguished by tag.
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.
| 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-LEGACY | latest | Delegate that auto upgrades with no flexibility to turn off auto upgrade (DEPRECATED) |
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 the following notification methods.
- Slack
- Microsoft Teams.
- PagerDuty
- Webhook
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.
For more information, go to Harness Secrets Management Overview.
In addition to the built-in Secret Manager, Harness Platform supports the cloud platform secrets management services in the following table.
| 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 |
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.
The following table lists the major supported features for Harness Self-Managed Enterprise Edition offerings.
| Solution | Supported Platform | Connected | HA | Monitoring | Disaster Recovery |
|---|---|---|---|---|---|
| Kubernetes Cluster | Kubernetes - GKE - AKS - EKS | Yes | Yes | Prometheus, Grafana | Yes |
Supported Kubernetes versions
- Self-Managed Enterprise Edition supports Kubernetes v.1.27, as well as versions 1.26, 1.25, 1.24, 1.23, 1.22, 1.21, and 1.20.
- Effective October 7, 2022, with the release of version 76918, Self-Managed Enterprise Edition no longer supports Kubernetes open-source versions 1.18 and earlier.
- Self-Managed Enterprise Edition supports the other versions of Kubernetes you use on a best-effort basis.
- Harness commits to support new minor versions of Kubernetes within three months of the first stable release. For example, if the stable release of 1.28.0 occurs on August 31, Harness extends compatibility by November 30.
Terms of support
The support policy is 12 months of full support, followed by 6 months of limited support for critical security fixes only.
Harness Self-Managed Enterprise Edition does not introduce changes that break compatibility with supported versions of Kubernetes. For example, Self-Managed Enterprise Edition does not use features from Kubernetes version n that do not work in Kubernetes version n-2.
Installation and upgrade preflight checks provide warnings when you use unsupported Kubernetes versions.
In cases where you encounter a problem related to an incompatibility issue, you must upgrade your cluster. Harness does not issue a patch to accommodate the use of unsupported Kubernetes versions.