This content is for Harness FirstGen. Switch to NextGen.Harness includes a built-in Secrets Management feature that enables you to store encrypted secrets, such as access keys, and use them in your Harness applications. Some key points about Secrets Management:
- Secrets are always accessed/decrypted at the time when they are needed, and at no time they are stored unencrypted.
- Harness Manager does not have access to your key management system, and only the Harness Delegate, which sits in your private network, has access to it. Harness never makes secrets management accessible publicly. This adds an important layer of security.
In this topic:
- Secrets How-tos
- Before You Begin
- Visual Summary
- Harness Secrets Management Process Overview
- Scoping Secrets Usage
- Secrets in Harness Community and On-Prem Accounts
- Adding Secrets Managers
- Managing Secrets
- Use Encrypted Text Secrets
- Use Encrypted File Secrets
- Migrate Secrets between Secrets Managers
- Restrict Secrets Usage
- Reference Existing Secrets
- Use Secrets in a Delegate Profile
- Add SSH Keys
- Use SSH Keys via Kerberos for Server Authentication
- Add HashiCorp Vault Signed SSH Certificate Keys
- Add WinRM Connection Credentials
Before You Begin
Before learning about, you should have an understanding of the following:
You can choose to use your own secrets management solution, or the built-in Harness Secrets Manager. This diagram shows how Harness handles secrets:
Harness Secrets Management Process Overview
Harness sends only encrypted data to the secrets manager, as follows:
- Your browser sends data over HTTPS to Harness Manager.
- Harness Manager relays encrypted data to the Harness Delegate, also over HTTPS.
- The Delegate exchanges a key pair with the secrets manager, over an encrypted connection.
- The Harness Delegate uses the encrypted key and the encrypted secret, and then discards them. The keys never leave the Delegate.
Any secrets manager requires a running Harness Delegate to encrypt and decrypt secrets. Any Delegate that references a secret requires direct access to the secrets manager.You can manage your secrets in Harness using either a Key Management Service or third party Secrets Managers.
Using Key Management Services
Google Cloud Key Management Service is the default Secrets Manager in Harness.
The Key Management Service (Google Cloud KMS or AWS KMS) only stores the key. Harness uses envelope encryption to encrypt and decrypt the secrets. The encrypted secret and the encrypted Data Encryption Key (used for envelope encryption) are stored in the Harness database.
If you are using a KMS, rotation of keys is not supported by Harness and you might lose access to your secrets if the older version of the key is removed from your KMS.
Using Third-Party Secrets Managers
You can also use third-party Secrets Managers — HashiCorp Vault, Azure Key Vault, and AWS Secrets Manager.
These Secrets Managers store the key, perform encryption and decryption, and also store the secrets (encrypted key pair). Neither the keys nor the secrets are stored in the Harness database. A reference to the secret is stored in the Harness database.
Scoping Secrets Usage
For scoping secrets, see Restrict Secrets Usage.
For scoping Secret Managers, see Scope Secret Managers to Applications and Environments.
Secrets in Harness Community and On-Prem Accounts
Once you have installed On-Prem, Add a Harness Secrets Manager. By default, On-Prem installations use the local Harness MongoDB for the default Harness Secrets Manager. This is not recommended.Harness does not currently support migrating secrets from the random-key secrets store. If you add secrets here, you will need to recreate them in any custom secrets manager you configure later.All Harness secrets managers require a running Harness Delegate to encrypt and decrypt secrets.
If you created a Harness trial account, a Delegate is typically provisioned by Harness, and the default Harness Secrets Manager performs encryption/decryption.