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 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.
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 will reach 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)
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.
We support what each of the Cloud Providers support. We recommend users to keep their binary versions up to date.
By default, Harness ships with kubectl client - 1.24.3
Harness has certified versions 1.25, 1.26, and 1.27 of kubectl. You must install the respective client version of the delegate for Harness to leverage it.
Tooling:
OpenShift - oc client binary
Kustomize - kustomize binary
Helm - Helm 3.12 and 2.8 binary.
Helm 3.8 can be supported via feature flag.
Limitations:
Helm:
Helm Hooks are not supported for this swimlane. Harness manages and orchestrates the manifests and their release.
Kustomize:
Kustomize Patches are only supported in YAML, not JSON
Helm deployments might start failing at the delegate due to a large index.yaml files. This causes a CPU spike on the delegate. If you do not provide enough resources to the delegate, you might see failures in pipeline executions.
Certified Limits:
Index.yaml file size limit 15Mb
5000 Helm charts have been deployed
Kubernetes delegate size: 8GB, 2 CPU
10 parallel deployments
Supported integrations:
Traffic Shifting for Advanced Deployment Strategies:
Istio
Nginx Ingress Controller
All manifest type sources for fetching Kubernetes resources:
Github
Gitlab
Bitbucket
Custom Remote Source Repository
Harness Local File Store
For Helm Chart Type Manifests we also support:
Generic Git Provider
Google Cloud Storage
Amazon S3 Storage
Helm OCI Repository (ACR, ECR, GAR, Artifactory)
Helm HTTP Server Repository (Nexus, Artifactory)
Artifact repository supported to deploy with manifest:
The following versions are tested and supported for Kubernetes Canary, Rolling, and Blue/Green deployments:
1.13.0
1.14.0
1.15.0
1.16.0
1.17.0
1.18.0
1.19.4
1.20.0
1.21.0
1.22.0
1.23.0
1.24.3
1.24.9
1.25.6
1.26.0
1.27.0
For details on other tools and versions included in Harness, see Delegate-required SDKs.
Guidelines:
Harness will officially support 3 previous versions from the last stable release. For example, the current most recent stable release is 1.25.6, and so Harness supports 1.24, 1.23, and 1.22.
Harness supports any other versions of Kubernetes you are using on a best effort basis.
Harness commits to support new minor versions within 3 months of the first stable release. For example, if the stable release of 1.25.6 occurs on April 15th, we will support it for compatibility by July 15th.
Harness only supports AWS Lambda Functions to be deployed via Serverless.com Framework
Harness builds and deploys Lambda Functions> You cannot split up the tasks to build functions and deploy functions separately as part of Harness support.
Not supported application types:
Google Functions
Azure Functions
Serverless.com 1.x (limited support). Not all capabilities supported.
Basic deployment supported. No out-of-the-box canary and blue green deployment supported.
Supported integrations:
Serverless.com plugins:
Harness supports all the Serverless.com plugins. Please make sure they are compatible with the version of Serverless.com you are using.
Continuous Integration (CI) can be performed in Harness using the module and CI pipelines.
If you are using Harness Continuous Delivery (CD) but not Harness Continuous Integration (CI), you can still perform CI using the Jenkins step in your CD stage.
Harness integrates with Jenkins, enabling you to run Jenkins jobs and dynamically capture inputs and outputs from the jobs.
Harness has been tested with the following versions of Jenkins:
Harness GitOps lets you perform GitOps deployments in Harness. You define the desired state of the service you want to deploy in your Git manifest, and then use Harness GitOps to sync state with your live Kubernetes cluster.
GitOps supports the following:
Argo CD version supported: 2.8.2.
Source Repositories:
All Git providers.
HTTP Helm repos.
Target clusters:
Kubernetes clusters hosted on any platform:
GKE.
AKS.
EKS.
Other Kubernetes-compliant clusters.
OpenShift version 3.11, 4.x.
Minikube.
Kubernetes Operations (kops).
Repository Certificates:
TLS Certificate (PEM format).
SSH Known Host Entry.
GnuPG Keys:
GnuPG Public Key Data (ASCII-armored).
Limitations:
Self-hosted environments
Agents installed in custom namespaces are not yet supported.
Local (Harness Community Edition)
Harness CD Community Edition is a lightweight version of Harness that you can download and run on your laptop or any VM.
Harness CD Community Edition is intended to get devs started with Harness quickly without having to sign up for a Harness SaaS account.
Harness does not include Terraform on the Harness Delegate. You must install Terraform on the Delegate when using Terraform in Harness. For more information, go to Terraform How-tos.
Harness supports the following Terraform versions:
v1.3.5
v1.1.9
v1.0.0
v0.15.5
v0.15.0
v0.14.0
Here's an example install script for the Harness delegate:
Harness Policy As Code uses Open Policy Agent (OPA) as the central service to store and enforce policies for the different entities and processes across the Harness platform.
You can centrally define and store policies and then select where (which entities) and when (which events) they will be applied.
Currently, you can define and store policies directly in the OPA service in Harness.
Soon, you will be able to use remote Git or other repos (e.g. OCI-compatible registries) to define and store the policies used in Harness.
When configuring a policy for testing, users must have a pipeline that has a policy run against it (success or failed) to capture the pipeline's expanded JSON for the policy studio testing terminal.
Policies can only be run against one document (one JSON payload sent for OPA evaluation). You cannot run a policy against multiple documents.
Not all Harness entities are supported with policies:
For CD: service, environment, infrastructure, and overrides are on the roadmap for integration.
For Platform: service account, API key, and token are on the roadmap for policy integration.
For other product modules: entities will be added as needed.
Harness does not support OPA bundles.
Harness does not support data imports from external sources.
Harness does not support allow, to support this use case you need to invert the logic, Harness OPA supports deny and not allow.
Triggers: The feature flag CD_GIT_WEBHOOK_POLLING must be enabled for Github polling with two factor authentication. For more information, go to Polling frequency.
ServiceNow: ServiceNow versions Utah and earlier are supported.
Jira: Jira on-premise versions < 9.0 are supported. To support Jira on-premise >= 9.0, the feature flag SPG_USE_NEW_METADATA must be enabled.
GitOps: The Harness GitOps Agent does not yet support installing agents in specific cluster namespaces in Self-Managed Enterprise Edition.
Policy as Code: Harness Git Experience support for OPA policies is not supported in Self-Managed Enterprise Edition.
Harness AI Development Assistant (AIDA): To support AIDA in Self-Managed Enterprise Edition running in an offline environment, you must add https://harness.openai.azure.com to your allowlist.
Harness supports most of the popular APM tools, but there may be instances where Harness don't have a native connector. Using the Harness Custom Health Source feature, you can integrate such APM tools with Harness.
Harness CV supports the following log management tools:
Datadog
Elasticsearch
Google Cloud Operations (formerly Stackdriver)
Grafana Loki
Splunk
Sumo Logic
Harness supports most of the popular log management tools, but there may be instances where Harness don't have a native connector. Using the Harness Custom Health Source feature, you can integrate such log management tools with Harness.
CCM FirstGen support is discontinued as of December 31, 2022. To migrate to Next Gen, please create Next Gen connectors and delete any existing First Gen connectors.
This topic provides the Harness Cloud Cost Management supported platforms and feature support matrix:
Different stakeholders in an organization care about different slices of your cloud data. Perspectives allow you to monitor the slice of data you are interested in. It also shows contextual recommendations and anomalies, tying in real time alerting and budgets to the specific style of data.
Perspectives can help you monitor cloud costs, tie them back to optimization opportunities, and set budget to govern costs along with reporting and alerting capabilities.
Single pane of glass across multiple cloud and cluster costs.
Slice and dice data across multiple dimensions across cloud providers.
Deep resource-level visibility for K8s and ECS clusters.
Resource-level granularity is not feasible in cloud perspectives
Perspective Preferences
Not supported for Azure and Kubernetes
RBAC is not supported
Data level and connector level RBAC is not supported
The total cost displayed on the perspective list page is pre-computed (performed once per day) and could potentially deviate from the real-time costs presented within the perspective.
Cost categories are a rule-based engine that attaches additional metadata to categorize cloud spending. Enabling organizations to align costs with context most relevant to their showback and chargeback models.
Cost categories also enable you to reshare specific costs (Shared) with different sharing strategies.
Any changes to the cost categories will only be reflective for the current month data onwards. Historical data will point to the state of cost categories at that point in time.
Cost category metadata attribution doesn’t work for any historical data, it is only from the point of cost category creation.
Not supported in dashboards for cluster, AWS, GCP & Azure models. Only supported in the Unified Model.
Shared cost data attribution of cost categories doesn’t flow into dashboards.
Perspectives limitations
Perspectives always rely on the current state of cost categories, everything is generated dynamically real-time.
Sharing of unallocated costs among cost buckets is not supported
Currency standardization allows you to view your cloud spend data in the currency of your choice. It provides more consistent, easy-to-consume, and meaningful cloud analytics across the entire business.
If you have cloud provider bills in different currencies, currency standardization helps you normalize all costs into a single currency of your choice.
After standardizing the currency, historical cluster data is not backfilled automatically. Today a support request has to be raised to replay/backfill data.
You can configure your preferred currency only once. It can't be updated later.
The currency symbol in dashboards don't change, but the cost values are displayed in the preferred currency.
Only 15 currencies are supported
Default currency conversion factor is picked up from the CUR and falls back to public API.
Option to change currency conversion factor. The new factor will be used to:
Reflect current month’s data and new data for cloud
Reflect current day’s data and new data for cluster
Currency representation based on locale. Default is en-us locale.
After configuring it may take up to 24 hours for the converted value to be displayed.
Anomaly detection helps detect unusual spending patterns in your clusters costs and cloud accounts. Cloud cost anomaly detection can be used as a tool to keep cloud costs under control. It also provides alerting capabilities (email and Slack) so that stakeholders are notified of each anomaly that's detected.
Early detection of unusual expenses: Anomaly detection can quickly identify unusual spending patterns or unexpected costs. This early detection allows businesses to address potential issues promptly, preventing further financial losses.
Realtime alerting: This can help relevant teams get notified proactively.
Data Visualization: BI Dashboards allows users to create interactive and visually appealing dashboards and reports. This makes it easier for users to understand complex data sets and gain insights.
Real-time Data Access: BI Dashboards enables users to access real-time data from various cloud sources. This ensures that users are making decisions based on the most up-to-date information.
Data Exploration and Discovery: BI Dashboards provides a powerful and user-friendly interface that empowers users to explore and analyze data on their own. Users can easily drill down into specific data points, apply filters, and perform ad-hoc analysis.
AutoStopping Rules offer a seamless way to optimize your non-production resources, ensuring they are active only when needed, and inactive when idle. With the added advantage of orchestrating workloads on spot instances, interruptions due to spot interruptions become a thing of the past. By implementing AutoStopping Rules:
CCM provides recommendations for your ECS clusters, workloads, node pools, Azure VMs, and AWS EC2 instances. Recommendations are also generated for asset governance policies. These recommendations show you resource optimization opportunities to potentially reduce your monthly spending.
The recommendations are computed by analyzing the past utilization of CPU and memory of your workload. The implementation uses a histogram method to compute the recommendations.
Cost optimisation: With recommendations you can get an overview of the potential cost savings on resources across your infrastructure.
Automated workflow: Automatically generated recommendations based on your past utilization data and trends.
Ticketing integration: Allows you to easily manage all the recommendations and facilitates comprehensive tracking of recommendation lifecycles across the system. CCM offers Jira and ServiceNow as the ticketing tools to manage all the recommendations within CCM. You are also provided with an option to ignore the recommendation if it is not applicable.
After onboarding the cloud or cluster connectors to CCM, it may take up to 48 hours for the recommendations to appear in the platform.
Azure VM, AWS EC2 Recommendations are pulled in from the Azure advisor & AWS cost optimizer respectively
Memory metrics are not considered when these recommendations are computed
Workload recommendations
15% buffer to the recommended resources by default
CPU limits are not recommended by the platform
The following labels are used to process node pool recommendations. Make sure to add one of the labels listed below for the respective cloud providers:
Amazon Web Services (AWS)
eks.amazonaws.com/nodegroup
alpha.eksctl.io/nodegroup-name
node-pool-name
kops.k8s.io/instancegroup
Google Cloud Platform (GCP)
cloud.google.com/gke-nodepool
node-pool-name
kops.k8s.io/instancegroup
Microsoft Azure
Agentpool
node-pool-name
kops.k8s.io/instancegroup
Potential savings
For Node pool recommendations, CCM uses public pricing to calculate costs.
For Workload and ECS recommendations, CCM uses the last day cost available from cluster data.
For EC2 and Azure VM recommendations, CCM fetches the values provided by the Cloud Provider themselves.
GCP VM recommendations are not supported
Notifications are not supported for recommendations
Identify cloud resources that are either orphaned or underutilized based on defined conditions. For example, display RDS instances with storage usage below 10% with a specific tag.
Set up enforcements that automatically trigger corrective measures upon condition fulfillment. This applies to individual rules, multiple rules, and rule sets across various accounts and regions. For example, configure an enforcement to automatically power down EC2 instances during off-peak hours, ensuring large-scale remediation.
Send a notification through Slack or call a webhook when policy conditions are met.
Harness CCM Budgets allow you to set custom budgets and receive alerts when your costs exceed (or are forecasted to exceed) your budget. You can create budgets for Harness Applications and clusters along with Budget groups. Audit trail is supported for budgets and budget groups.
Alerts and notifications: Support for email and slack alerts to effectively monitor your customized budgets, ensuring your costs align with your anticipated targets.
Budget grouping: Allows you to categorize and organize budgets into distinct and logical groups based on specific criteria.
Budget support for various time ranges: Allows you to establish financial limits for specific periods.
Set budgets for forecasted costs: Allows you to project future expenditures for better financial management.
Review the following information about what installation infrastructure and CCM features are supported on Harness Self-Managed Enterprise Edition.
Supported installation infrastructure for CCM on Harness Self-Managed Enterprise Edition
AWS is the only supported installation infrastructure. If you do not install Harness Self-Managed Enterprise Edition on AWS, then you cannot use the CCM features.
Supported CCM features on Harness Self-Managed Enterprise Edition
The following table provides the feature support matrix for CCM on Harness Self-Managed Enterprise Edition.
Features
AWS
Azure
GCP
Kubernetes
Connected environment
Air-gapped environment
Perspectives
✅
✅
✅
✅
✅
✅
Cost categories
✅
✅
✅
✅
✅
✅
Budgets
✅
✅
✅
✅
✅
✅
BI dashboards
✅
✅
✅
✅
✅
✅
Anomaly detection
✅
✅
✅
✅
✅
✅
Currency standardization
❌
❌
❌
❌
❌
❌
Recommendations
✅
✅
✅
✅
✅
✅
AutoStopping
❌
❌
❌
❌
❌
❌
Asset governance
❌
❌
❌
❌
❌
❌
note
Perspective preferences are not supported on Harness SMP.
The cost data for Kubernetes workloads will be derived from the public pricing provided by the respective cloud provider.
Tracking recommendation lifescyle through Jira and ServiceNow is not supported in Air-gapped environments.
CCM leverages AWS APIs that require connectivity from the isolated (air-gapped) instance. To grant access to these AWS APIs, establish VPC endpoints for the respective AWS services. For services lacking VPC endpoints, use a proxy to facilitate access. For more information, go to Manage AWS costs by using CCM on Harness Self-Managed Enterprise Edition.
For a comprehensive list of supported features in other Harness modules and the Harness Platform overall, go to Supported platforms and technologies.
A Health Source monitors changes in health trends of the Service using metrics and logs collected from an APM and log provider respectively.
Harness offers support for all major APM vendors, but there are cases where a customized APM is needed. The Custom Health Source lets you customize APMs of your choice.
Manage code within Harness and accelerate development with security at scale.
The Harness Code Repository module is a source code management (SCM) tool that fosters developer collaboration and accelerates innovation while keeping security and compliance in mind. Git-based repositories are seamlessly integrated across your software delivery processes in Harness. Collaborative code reviews with checks and rules enforcement foster teamwork, reduce risk, and maintain code quality.
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.
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.
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.
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.
When you delete an existing template with active pipeline references, Harness deletes the references.
When you convert a runtime input in a template to a fixed value, the input type does not change in the linked pipeline. You must manually edit the linked pipeline YAML and provide the fixed values.
When you convert a fixed type input to a runtime input in your template, the input type does not change in the linked pipeline. You must click the template in the linked pipeline to refresh it and save the pipeline again. This re-initiates the reconciliation process.
Chained pipeline stages are not supported with pipeline templates.
When using multiple nested templates, you must manually reconcile the changes or force reconcile via the three-dots menu.
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.
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.
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.
Harness IDP supports a number of plugins to integrate the software catalog with third-party providers. Please find the growing list of supported plugins. This is a subset of the Backstage plugin marketplace.