Integrate your Edge site with your vault

Important This feature is available only in the latest UI.

Important This topic uses the Edge CLI. If you still use the deprecated Edge tool, go to the Edge Tool documentation to review the relevant commands. Keep in mind that the Edge Tool will be end of life with the February 2025.02 release.

You can integrate Edge site with your vault provider to more easily manage your data source information and set up your Edge site connections.

Available vaults

Tip

Select your Kubernetes cluster:

Bundled k3s Managed Kubernetes

You can use a vault to add your data source information to your site connection.

AWS Secrets Manager

Azure Key Vault

CyberArk Vault

Google Secret Manager

HashiCorp Vault

Select your authentication method:

AWS Secrets Manager
Azure Key Vault
CyberArk Vault
Google Secret Manager
HashiCorp Vault

Integrate your CyberArk Vault with your Edge site connections by adding a vault to your Edge site.

You can connect to your CyberArk Vault using the following authentication methods:

mTLS
allow-list

Prerequisites

Ensure that your environment uses the latest user interface.
You installed your Edge site.
You have a global role that has the Manage Edge sites global permission.
You have access to the data source that will use the vault credentials.
You installed and configured the Edge CLI tool.
You have a CyberArk Vault .
Your CyberArk Vault is configured with either Allowed machines (allow-list) or Client certificates (mTLS).
You can administer CyberArk secrets. This includes the ability to do the following in your CyberArk Vault :
- Create
- Edit
- Delete
- Rotate credentials
Your CyberArk Credential Provider has GetPassword Web Service available in /AIMWebService.
If you use a --caPath, it must be in the X.509 format (PEM encoded).
If you use a --certPath, it must be in the X.509 format (PEM encoded).
If you use a --keyPath, it must be in the PKCS#8 format (PEM encoded).

Note There are a few limitations with the CyberArk Vault integration:

Forward proxies are not supported.
There must be a direct connection between your Edge site and CyberArk. You can only use scalar values. If your Edge site connection requires a Certificate or any other type of extra parameter, you can't use the CyberArk Vault integration.
Pass phrase protected certificates are not currently supported.

Steps

In the cluster where your Edge site is installed, use the Edge CLI tool to run the command for the mTLSallow-list authentication method.

Copy

sudo ./edgecli vault create cyber tls "<name>" \
  --desc "<description>" \
  --appId "<appId>" \
  --url "<url>" \
  --caPath "<caPath>" \
  --certPath "<certPath>" \
  --keyPath "<keyPath>"

Copy

./edgecli vault create cyber tls "<name>" \
  --desc "<description>" \
  --appId "<appId>" \
  --url "<url>" \
  --caPath "<caPath>" \
  --certPath "<certPath>" \
  --keyPath "<keyPath>"

Command	Description
`<name>` (required)	The name of the vault instance. It is required and it must be unique within an Edge site. For Kubernetes guidelines on the required naming conventions of the <name> parameter, go to Labels and Selectors. Note The name can only contain alphanumeric, dash (-), underscore ( _ ), or period (.) characters. The name cannot include white spaces or special characters such as /, !, ?.
`<description>` (optional)	The description of the vault instance. The maximum character length is 150.
`<appId>` (required)	The application ID configured on the CyberArk server.
`<url>` (required)	The URL of your CyberArk Vault .
`<caPath>` (required)	The file containing the Certificate Authority. If you use a `--caPath`, it must be in the X.509 format (PEM encoded).
`<certPath>` (required)	The file containing the Client Certificate. If you use a `--certPath`, it must be in the X.509 format (PEM encoded).
`<keyPath>` (required)	The file containing the Client Private Key. If you use a `--keyPath`, it must be in the PKCS#8 format (PEM encoded).

Note For more information about how to configure your CyberArk Vault integration, go to the following CyberArk resources:

Show me an example…

sudo ./edgecli vault create cyber tls "Edge CyberArk Vault mTLS" \
  --desc "CyberArk vault with mTLS authentication." \
  --appId "edge" \
  --url "https://edge-cyberark-server.example.com" \
  --caPath "./certs/ca.crt" \
  --certPath "./certs/aimws.crt" \
  --keyPath "./certs/aimws-pkcs8.key"

Copy

sudo ./edgecli vault create cyber allow-list "<name>" \
  --desc "<description>" \
  --appId "<appId>" \
  --url "<url>" \
  --caPath "<caPath>"

Copy

./edgecli vault create cyber allow-list "<name>" \
  --desc "<description>" \
  --appId "<appId>" \
  --url "<url>" \
  --caPath "<caPath>"

Command	Description
`<name>` (required)	The name of the vault instance. It is required and it must be unique within an Edge site. For Kubernetes guidelines on the required naming conventions of the <name> parameter, go to Labels and Selectors. Note The name can only contain alphanumeric, dash (-), underscore ( _ ), or period (.) characters. The name cannot include white spaces or special characters such as /, !, ?.
`<description>` (optional)	The description of the vault instance.
`<appId>` (required)	The application ID configured on the CyberArk server.
`<url>` (required)	The URL of your CyberArk Vault .
`<caPath>` (required)	The file containing the Certificate Authority. If you use a `--caPath`, it must be in the X.509 format (PEM encoded).

Note For more information about how to configure your CyberArk Vault integration, go to the following CyberArk resources:

Show me an example…

sudo ./edgecli vault create cyber allow-list "Edge CyberArk allowlist" \
--desc "CyberArk vault with allowlist authentication." \
--appId "edge" \
--url "https://edge-cyberark-server.example.com" \
--caPath "./certs/ca.crt"

Your available vault integrations are visible on the Vaults tab of your Edge site.

Note If you need help using the Edge CLI, use the following help command:

Copy

sudo ./edgecli vault create "<vault>" "<authMethod>" -h

Copy

./edgecli vault create "<vault>" "<authMethod>" -h

What's next?

You can now set up an Edge connection with your CyberArk Vault .
You can retrieve and review the configuration details of your vault integrations.
You can edit your vault integration configuration.

Integrate your HashiCorp Vault with your Edge site connections by adding a vault to your Edge site.

Prerequisites

Ensure that your environment uses the latest user interface.
You installed your Edge site.
You have a global role that has the Manage Edge sites global permission.
You have access to the data source that will use the vault credentials.
You installed and configured the Edge CLI tool.
You have a HashiCorp Vault.
You or another user can administer HashiCorp Vault secrets. This includes the ability to do the following in your HashiCorp Vault:
- Create
- Edit
- Delete
- Rotate credentials
You or another user have read credentials to the Authentication method and the HashiCorp Vault secret engine.
If you use a --caPath, it must be in the X.509 format (PEM encoded).
If you use a --certPath, it must be in the X.509 format (PEM encoded).
If you use a --keyPath, it must be in the PKCS#8 format (PEM encoded).

Note There are a few limitations with the HashiCorp Vault integration:

Forward proxies are not supported for HashiCorp Vault integrations. You must have a direct connection to your HashiCorp Vault.
HashiCorp Vault passwords are formatted as a map structure, in key/value pairs, for the two supported database engines.
- Key Value V2 secrets engine: A Field value is supplied to extract the value from the map structure for a scalar secret value.
- Database secrets engine: A pair of fields is available: username and password. These key names are fixed.
Only two authorization engines are currently supported:
- User-pass
- TLS

Steps

In the cluster where your Edge site is installed, use the Edge CLI tool to run the command for the username and passwordTLS authentication method:

Copy

sudo ./edgecli vault create hashicorp user-pass "<name>" \
  --desc "<description>" \
  --user "<username>" \
  --pass "<password>" \
  --caPath "<caPath>" \
  --url "<url>"
  --vaultNamespace "<vaultNamespace>"

Copy

./edgecli vault create hashicorp user-pass "<name>" \
  --desc "<description>" \
  --user "<username>" \
  --pass "<password>" \
  --caPath "<caPath>" \
  --url "<url>"
  --vaultNamespace "<vaultNamespace>"

Command	Description
`<name>` (required)	The name of the vault instance. It is required and it must be unique within an Edge site. For Kubernetes guidelines on the required naming conventions of the `<name>` parameter, go to Labels and Selectors. Note The name can only contain alphanumeric, dash (-), underscore ( _ ), or period (.) characters. The name cannot include white spaces or special characters such as /, !, ?.
`<description>` (optional)	The description of the vault instance. The maximum character length is 150.
`<user>` (required)	The username for your vault.
`<pass>` (required)	The password for your vault.
`<caPath>` (optional)	The file containing the Certificate Authority. If you use `--caPath` it must be in the PKCS#8 format. Note A `--caPath` file is optionally included for the creation of the authentication endpoint. It will not be required if the HTTP endpoint is used for the Username/Password authentication. The HTTP endpoint is used for the Username/Password authentication.
`<url>` (required)	The URL of the HashiCorp Vault.
`<vaultNamespace>` (optional)	A unique namespace in your vault.

Show me an example…

sudo ./edgecli vault create hashicorp user-pass "Hasicorp-Vault-Username-Password-AuthN" \
  --desc "HashiCorp vault with user-pass authentication." \
  --user "my-edge-site" \
  --pass "EdgePass123" \
  --caPath "~/hashicorp/vault/ca.pem" \
  --url "https://hashicorp-vault.edge.collibra/" \
  --vaultNamespace "HashiCorp vault 45"

Copy

sudo ./edgecli vault create hashicorp tls "<name>" \
  --authName "<authName>"
  --desc "<description>" \
  --caPath "<caPath>" \
  --certPath "<certPath>" \
  --keyPath "<keyPath>" \
  --url "<url>"
  --vaultNamespace "<vaultNamespace>"

Copy

./edgecli vault create hashicorp tls "<name>" \
  --authName "<authName>"
  --desc "<description>" \
  --caPath "<caPath>" \
  --certPath "<certPath>" \
  --keyPath "<keyPath>" \
  --url "<url>"
  --vaultNamespace "<vaultNamespace>"

Command	Description
`<name>` (required)	The name of the vault instance. It is required and it must be unique within an Edge site. For Kubernetes guidelines on the required naming conventions of the `<name>` parameter, go to Labels and Selectors. Note The name can only contain alphanumeric, dash (-), underscore ( _ ), or period (.) characters. The name cannot include white spaces or special characters such as /, !, ?.
`<authName>` (required)	The name of the HashiCorp Vault endpoint.
`<description>` (optional)	The description of the vault instance. The maximum character length is 150.
`<caPath>` (optional)	The file containing the Certificate Authority. If you use `--caPath` it must be in the PKCS#8 format. Note A `--caPath` file is optionally included for the creation of the authentication endpoint. It will not be required if the HTTPS certificate used for the SSL/TLS endpoint termination has a certificate chain supplied and the root certificate is in a Java trust store.
`<certPath>` (required)	The file containing the Client Certificate.
`<keyPath>` (required)	The file containing the Client Private Key.
`<url>` (required)	The URL of the HashiCorp Vault.
`<vaultNamespace>` (optional)	A unique namespace in your vault.

Show me an example…

sudo ./edgecli vault create hashicorp tls "tls-vault-auth" \
  --authName "tls-vault-auth" \"
  --desc "HashiCorp vault with tls authentication." \
  --caPath "~/hashicorp/vault/ca.pem" \
  --certPath "~/hashicorp/vault/edge-site.crt" \
  --keyPath "~/hashicorp/vault/edge-site.key" \
  --url "https://hashicorp-vault.edge.collibra/"
  --vaultNamespace "HashiCorp vault 45"

Your available vault integrations are visible on the Vaults tab of your Edge site.

Note If you need help using the Edge CLI, use the following help command:

Copy

sudo ./edgecli vault create "<vault>" "<authMethod>" -h

Copy

./edgecli vault create "<vault>" "<authMethod>" -h

What's next?

You can now set up an Edge connection with your HashiCorp Vault .
You can retrieve and review the configuration details of your vault integrations.
You can edit your vault integration configuration.

Integrate your Azure Key Vault with your Edge site connections by adding a vault to your Edge site.

You can connect to your Azure Key Vault using the following authentication methods:

Managed Identity assigned to Azure Virtual Machine
Service Principal Secret
Service Principal with PEM certificate
Service Principal with PFX certificate

Prerequisites

Ensure that your environment uses the latest user interface.
You installed your Edge site.
- In order to use the Managed Identity assigned to Azure Virtual Machine authentication method, you must install your Edge site inside of the Azure VM.
You have a global role that has the Manage Edge sites global permission.
You have access to the data source that will use the vault credentials.
You installed and configured the Edge CLI tool.
You have an Azure Key Vault.
You have the following Azure Key Vault roles or permissions:
- If you use Access Policies, you must have the Get and List Secret permissions.
- If you use Access Control (IAM), you must have the Key Vault Secrets User role, or a role with similar permissions.
You generated a client secret for the Azure Service Principal.
You generated a PEM certificate for the Azure Service Principal.
You generated a PFX certificate for the Azure Service Principal.
You assigned the managed identity to the Azure VM.
You created secrets in your Azure Key Vault.

Note There are a few limitations with the Azure Key Vault integration:

Forward proxies are not supported for Azure Key Vault integrations. You must have a direct connection to your Azure Key Vault.
Only scalar values are accepted for the Azure Key Vault. Each secret needs to resolve a single plain value or file.
Only the latest version of secrets can be accessed by your Edge site. You cannot set up and choose from different secret versions.

Steps

In the cluster where your Edge site is installed, use the Edge CLI tool to run the command for the managed identity assigned to the Azure VMservice principal secretservice principal with PEM certificateservice Principal with PFX certificate authentication method.

Copy

sudo ./edgecli vault create azure managed-identity "<name>" \
  --desc "<description>" \
  --dnsSuffix "<dnsSuffix>"

Copy

./edgecli vault create azure managed-identity "<name>" \
  --desc "<description>" \
  --dnsSuffix "<dnsSuffix>"

Command	Description
`<name>` (required)	The name of the vault instance. It is required and it must be unique within an Edge site. For Kubernetes guidelines on the required naming conventions of the <name> parameter, go to Labels and Selectors. Note The name can only contain alphanumeric, dash (-), underscore ( _ ), or period (.) characters. The name cannot include white spaces or special characters such as /, !, ?.
`<description>` (optional)	The description of the vault instance. The maximum character length is 150.
`<dnsSuffix>`	The data-plane endpoint for your vault. Note `<dnsSuffix>` is required if you use a private version of Azure for security purposes. For example, for FedRAMP, you would need to specify the Azure US Government DNS suffix: `vault.usgovcloudapi.net`. Otherwise, Edge uses the default value: `.vault.azure.net`.

Show me an example…

sudo ./edgecli vault create azure managed-identity "Azure-managed-identity" \
  --desc "Azure Key vault with managed identity authentication." 
  --dnsSuffix "vault.azure.net"

Copy

sudo ./edgecli vault create azure sp-secret "<name>" \
  --desc "<description>" \
  --dnsSuffix "<dnsSuffix>" \
  --tenantId "<tenantId>" \
  --clientId "<clientId>" \
  --clientSecret "<clientSecret>"

Copy

./edgecli vault create azure sp-secret "<name>" \
  --desc "<description>" \
  --dnsSuffix "<dnsSuffix>" \
  --tenantId "<tenantId>" \
  --clientId "<clientId>" \
  --clientSecret "<clientSecret>"

Command	Description
`<name>` (required)	The name of the vault instance. It is required and it must be unique within an Edge site. For Kubernetes guidelines on the required naming conventions of the <name> parameter, go to Labels and Selectors. Note The name can only contain alphanumeric, dash (-), underscore ( _ ), or period (.) characters. The name cannot include white spaces or special characters such as /, !, ?.
`<description>` (optional)	The description of the vault instance. The maximum character length is 150.
`<dnsSuffix>`	The data-plane endpoint for your vault. Note `<dnsSuffix>` is required if you use a private version of Azure for security purposes. For example, for FedRAMP, you would need to specify the Azure US Government DNS suffix: `vault.usgovcloudapi.net`. Otherwise, Edge uses the default value: `.vault.azure.net`.
`<tenantId>` (required)	The unique identifier of the Azure AD instance that the Azure Key Vault belongs to.
`<clientId>` (required)	The identifier of the service principal client.
`<clientSecret>` (required)	The secret of the service principal client.

Show me an example…

sudo ./edgecli vault create azure sp-secret "Azure-service-principal" \
  --desc "Azure Key vault with service principal secret authentication." \
  --dnsSuffix "vault.azure.net" \
  --tenantId "165" \
  --clientId "AZ_22" \
  --clientSecret "Secret123"

Copy

sudo ./edgecli vault create azure sp-pem "<name>" \
  --desc "<description>" \
  --dnsSuffix "<dnsSuffix>" \
  --tenantId "<tenantId>" \
  --clientId "<clientId>" \
  --certPath "<certPath>"

Copy

./edgecli vault create azure sp-pem "<name>" \
  --desc "<description>" \
  --dnsSuffix "<dnsSuffix>" \
  --tenantId "<tenantId>" \
  --clientId "<clientId>" \
  --certPath "<certPath>"

Command	Description
`<name>` (required)	The name of the vault instance. It is required and it must be unique within an Edge site. For Kubernetes guidelines on the required naming conventions of the <name> parameter, go to Labels and Selectors. Note The name can only contain alphanumeric, dash (-), underscore ( _ ), or period (.) characters. The name cannot include white spaces or special characters such as /, !, ?.
`<description>` (optional)	The description of the vault instance. The maximum character length is 150.
`<dnsSuffix>`	The data-plane endpoint for your vault. Note `<dnsSuffix>` is required if you use a private version of Azure for security purposes. For example, for FedRAMP, you would need to specify the Azure US Government DNS suffix: `vault.usgovcloudapi.net`. Otherwise, Edge uses the default value: `.vault.azure.net`.
`<tenantId>` (required)	The unique identifier of the Azure AD instance that the Azure Key Vault belongs to.
`<clientId>` (required)	The identifier of the service principal client.
`<certPath>` (required)	The file containing the Client Certificate.

Show me an example…

sudo ./edgecli vault create azure sp-secret "Azure-service-principal-PEM" \
  --desc "Azure Key vault with service principal with PEM cert authentication." \
  --dnsSuffix "vault.azure.net" \
  --tenantId "165" \
  --clientId "AZ_22" \
  --certPath "~/azurekey/vault/edge-site.pem"

Copy

sudo ./edgecli vault create azure sp-pfx "<name>" \
  --desc "<description>" \
  --dnsSuffix "<dnsSuffix>" \
  --tenantId "<tenantId>" \
  --clientId "<clientId>" \
  --certPath "<certPath>" \
  --certPassword "<certPassword>"

Copy

./edgecli vault create azure sp-pfx "<name>" \
  --desc "<description>" \
  --dnsSuffix "<dnsSuffix>" \
  --tenantId "<tenantId>" \
  --clientId "<clientId>" \
  --certPath "<certPath>" \
  --certPassword "<certPassword>"

Command	Description
`<name>` (required)	The name of the vault instance. It is required and it must be unique within an Edge site. For Kubernetes guidelines on the required naming conventions of the <name> parameter, go to Labels and Selectors. Note The name can only contain alphanumeric, dash (-), underscore ( _ ), or period (.) characters. The name cannot include white spaces or special characters such as /, !, ?.
`<description>` (optional)	The description of the vault instance. The maximum character length is 150.
`<dnsSuffix>`	The data-plane endpoint for your vault. Note `<dnsSuffix>` is required if you use a private version of Azure for security purposes. For example, for FedRAMP, you would need to specify the Azure US Government DNS suffix: `vault.usgovcloudapi.net`. Otherwise, Edge uses the default value: `.vault.azure.net`.
`<tenantId>` (required)	The unique identifier of the Azure AD instance that the Azure Key Vault belongs to.
`<clientId>` (required)	The identifier of the service principal client.
`<certPath>` (required)	The file containing the Client Certificate.
`<certPassword>` (required)	The password used to protect the PFX certificate.

Show me an example…

sudo ./edgecli vault create azure sp-secret "Azure-service-principal-PFX" \
  --desc "Azure Key vault with service principal with PFX cert authentication." \
  --dnsSuffix "vault.azure.net" \
  --tenantId "165" \
  --clientId "AZ_22" \
  --certPath "~/azurekey/vault/edge-site.pfx" \
  --certPassword "AZ_PFX_password1"

Your available vault integrations are visible on the Vaults tab of your Edge site.

Note If you need help using the Edge CLI, use the following help command:

Copy

sudo ./edgecli vault create "<vault>" "<authMethod>" -h

Copy

./edgecli vault create "<vault>" "<authMethod>" -h

What's next?

You can now set up an Edge connection with your Azure Key Vault .
You can retrieve and review the configuration details of your vault integrations.
You can edit your vault integration configuration.

Integrate your AWS Secrets Manager with your Edge site connections by adding a Vault to your Edge site.

Note

Edge sites already running on AWS have Instance Profiles and the Assume role.
Edge sites running outside of AWS can connect to the Secrets Manager by using an access key.

You can connect to your AWS Secrets Manager using the following authentication methods:

IAM Access Key
Instance Profile
Assume Role
- Assume Role is similar to Instance Profile, but allows you to narrow down the access to your vault to a singe role.

Prerequisites

Ensure that your environment uses the latest user interface.
You installed your Edge site.
- If you are using the Instance Profile authentication method, your Edge site must be running on an EC2 or EKS instance assigned to an Instance Profile that has access to the AWS Secrets Manager you want to connect to.
- If you are using the Assume Role authentication method, your Edge site must be running on an EC2 or EKS instance assigned to an Instance Profile that with access to role that has read access to the AWS Secrets Manager you want to connect to.
You have a global role that has the Manage Edge sites global permission.
You have access to the data source that will use the vault credentials.
You installed and configured the Edge CLI tool.
Your Edge site has network access to the AWS Secrets Manager endpoints.
You have a AWS Secrets Manager.
If your AWS Secret Manager uses either the Assume Role or Instance Profile authentication method, IMDSv1 or IMDSv2 must be enabled.
- If you have IMDSv2 enabled, you must run the following command from an AWS Secrets Manager admin account to set the hop limit to 2:
  Copy
```
aws ec2 modify-instance-metadata-options --instance-id <instance-id> --http-tokens required --http-endpoint enabled --http-put-response-hop-limit 2
```
You created secrets in your AWS Secrets Manager.
- If you are using the IAM Access Key authentication method, you must create IAM credentials with read access to the AWS Secrets Manager where your Edge site secrets will be stored.

Note Forward proxies are not supported for AWS Secrets Manager integrations. You must have a direct connection to your AWS Secrets Manager.

Steps

In the cluster where your Edge site is installed, use the Edge CLI tool to run the command for the IAM access keyinstance profileassume role authentication method.

Copy

sudo ./edgecli vault create aws key-secret "<name>" \
  --desc="<description>" \
  --region="<region>" \
  --endpointOverride="<endpointOverride>" \
  --accessKeyId="<accessKeyId>" \
  --accessKey="<accessKey>"

Copy

./edgecli vault create aws key-secret "<name>" \
  --desc="<description>" \
  --region="<region>" \
  --endpointOverride="<endpointOverride>" \
  --accessKeyId="<accessKeyId>" \
  --accessKey="<accessKey>"

Command	Description
`<name>` (required)	The name of the vault instance. It is required and it must be unique within an Edge site. For Kubernetes guidelines on the required naming conventions of the <name> parameter, go to Labels and Selectors. Note The name can only contain alphanumeric, dash (-), underscore ( _ ), or period (.) characters. The name cannot include white spaces or special characters such as /, !, ?.
`<description>` (optional)	The description of the vault instance. The maximum character length is 150.
`<region>`	The region of the AWS Secrets Manager you want to use. Note Region is optional if your Edge site and AWS Secrets Manager are both located in the same AWS region. Region is required if: You are using `<endpointOverride>`. Your Edge site is on k3s and running in AWS. Your Edge site is running in a different region than the AWS Secrets Manager you want to connect to.
`<endpointOverride>`	The URL of the entry point for your AWS Secrets Manager vault. Note `<endpointOverride>` is required if you use a private version of AWS for security purposes. For example, for FIPS, you would need to specify the FIPS endpoint: `<protocol>"://://"<service-code>"-fips."<region>".amazonaws.com`. Otherwise, Edge will use the default regional value: `"<protocol>"://"<service-code>"."<region-code>".amazonaws.com`
`<accessKeyId>` (required)	The ID of the IAM key you want to authenticate with.
`<accessKey>` (required)	The IAM key you want to authenticate with.

Show me an example…

sudo ./edgecli vault create aws key-secret "AWS-IAM" \
  --desc="AWS vault with IAM Access Key authentication." \
  --region="eu-west-1" \
  --endpointOverride="http://my-secret-vault.aws.com" \
  --accessKeyId="1234" \
  --accessKey="abcd"

Copy

sudo ./edgecli vault create aws instance-profile "<name>" \
  --desc="<description>" \
  --region="<region>" \
  --endpointOverride="<endpointOverride>"

Copy

./edgecli vault create aws instance-profile "<name>" \
  --desc="<description>" \
  --region="<region>" \
  --endpointOverride="<endpointOverride>"

Command	Description
`<name>` (required)	The name of the vault instance. It is required and it must be unique within an Edge site. For Kubernetes guidelines on the required naming conventions of the <name> parameter, go to Labels and Selectors. Note The name can only contain alphanumeric, dash (-), underscore ( _ ), or period (.) characters. The name cannot include white spaces or special characters such as /, !, ?.
`<description>` (optional)	The description of the vault instance. The maximum character length is 150.
`<region>`	The region of the AWS Secrets Manager you want to use. Note Region is optional if your Edge site and AWS Secrets Manager are both located in the same AWS region. Region is required if: You are using `<endpointOverride>`. Your Edge site is on k3s and running in AWS. Your Edge site is running in a different region than the AWS Secrets Manager you want to connect to.
`<endpointOverride>`	The URL of the entry point for your AWS Secrets Manager. Note `<endpointOverride>` is required if you use a private version of AWS for security purposes. For example, for FIPS, you would need to specify the FIPS endpoint: `<protocol>"://://"<service-code>"-fips."<region>".amazonaws.com`. Otherwise, Edge will use the default regional value: `"<protocol>"://"<service-code>"."<region-code>".amazonaws.com`

Show me an example…

sudo ./edgecli vault create aws instance-profile "AWS-Instance" \
  --desc="AWS vault with Instant Profile authentication" \
  --region="eu-west-1" \
  --endpointOverride="http://my-secret-vault.aws.com"

Copy

sudo ./edgecli vault create aws assume-role "<name>" \
  --desc="<description>" \
  --roleArn="<roleArn>"
  --roleSessionName="<roleSessionName>"
  --region="<region>"\
  --endpointOverride="<endpointOverride>"

Copy

./edgecli vault create aws assume-role "<name>" \
  --desc="<description>" \
  --roleArn="<roleArn>"
  --roleSessionName="<roleSessionName>"
  --region="<region>"\
  --endpointOverride="<endpointOverride>"

Command	Description
`<name>` (required)	The name of the vault instance. It is required and it must be unique within an Edge site. For Kubernetes guidelines on the required naming conventions of the <name> parameter, go to Labels and Selectors. Note The name can only contain alphanumeric, dash (-), underscore ( _ ), or period (.) characters. The name cannot include white spaces or special characters such as /, !, ?.
`<description>` (optional)	The description of the vault instance. The maximum character length is 150.
`<roleArn>` (required)	The Amazon Resource name of the role you want your Edge site to assume when accessing the AWS Secrets Manager secrets. Note In order for your Edge site to successfully assume this specified role, the Instance Profile role that is attached to the EKS cluster must be trusted by the target role.
`<roleSessionName>` (optional)	The name of the session you want this role to appear as in AWS security logs.
`<region>`	The region of the AWS Secrets Manager you want to use. Note Region is optional if your Edge site and AWS Secrets Manager are both located in the same AWS region. Region is required if: You are using `<endpointOverride>`. Your Edge site is on k3s and running in AWS. Your Edge site is running in a different region than the AWS Secrets Manager you want to connect to.
`<endpointOverride>`	The URL of the entry point for your AWS Secrets Manager. Note `<endpointOverride>` is required if you use a private version of AWS for security purposes. For example, for FIPS, you would need to specify the FIPS endpoint: `<protocol>"://://"<service-code>"-fips."<region>".amazonaws.com`. Otherwise, Edge will use the default regional value: `"<protocol>"://"<service-code>"."<region-code>".amazonaws.com`

Show me an example…

sudo ./edgecli vault create aws instance-profile "AWS-Assume" \
  --desc="AWS vault with Assume Role authentication" \
  --roleArn="edge-session"
  --roleSessionName="edge-session"
  --region="eu-west-1" \
  --endpointOverride="http://my-secret-vault.aws.com"

Your available vault integrations are visible on the Vaults tab of your Edge site.

Note If you need help using the Edge CLI, use the following help command:

Copy

sudo ./edgecli vault create "<vault>" "<authMethod>" -h

Copy

./edgecli vault create "<vault>" "<authMethod>" -h

What's next?

You can now set up an Edge connection with your AWS Secrets Manager .
You can retrieve and review the configuration details of your vault integrations.
You can edit your vault integration configuration.

Integrate your Google Secret Manager with your Edge site connections by adding a vault to your Edge site.

You can connect to your Google Secret Manager using the following authentication methods:

IAM Role assigned to the Google Cloud Engine VM
Service Account JSON Key
Service Account P12 Key

Prerequisites

Ensure that your environment uses the latest user interface.
You installed your Edge site.
- In order to use the IAM Role assigned to the Google Cloud Engine VM authentication method, you must install your Edge site inside of the Google Cloud Engine VM.
You have a global role that has the Manage Edge sites global permission.
You have access to the data source that will use the vault credentials.
You installed and configured the Edge CLI tool.
You have a Google Cloud account.
Your Google Secret Manager account must have the following permissions:
- iam.serviceAccounts.getAccessToken
- resourcemanager.projects.get
- secretmanager.secrets.get
- secretmanager.secrets.getIamPolicy
- secretmanager.secrets.list
- secretmanager.versions.access
- secretmanager.versions.get
- secretmanager.versions.list
You assigned a Google Service Account to the Google Cloud Engine VM where your Edge site secrets will be stored.
Your Edge site has network access to the Google Secret Manager endpoints.
You generated a JSON key for the Google Service Account.
You generated P12 key for Google Service Account.
Note P12 is a deprecated key type for backwards compatibility. The steps provided in Google's documentation about creating access credentials are intended for JSON. You can still follow the same steps for P12, with the only difference being the selection of the P12 Key Type instead of JSON.
You created secrets in your Google Secret Manager.

Note There are a few limitations with the Google Secret Manager integration:

Forward proxies are not supported for Google Secret Manager integrations. You must have a direct connection to your Google Secret Manager.
Only scalar values are accepted for the Google Secret Manager. Each secret needs to resolve a single plain value or file.
Only the latest version of secrets can be accessed by your Edge site. You cannot set up and choose from different secret versions.

Required permissions

You have access to both Edge management and your connections data sources that will use the vault credentials.

Steps

In the cluster where your Edge site is installed, use the Edge CLI tool to run the command for the IAM role assigned to the Google Cloud Engine VMJSON keyP12 key authentication method.

Copy

sudo ./edgecli vault create gcp iam-role "<name>" \
  --desc="<description>" \
  --projectId="<projectId>"

Copy

./edgecli vault create gcp iam-role "<name>" \
  --desc="<description>" \
  --projectId="<projectId>"

Command	Description
`<name>` (required)	The name of the vault instance. It is required and it must be unique within an Edge site. For Kubernetes guidelines on the required naming conventions of the <name> parameter, go to Labels and Selectors. Note The name can only contain alphanumeric, dash (-), underscore ( _ ), or period (.) characters. The name cannot include white spaces or special characters such as /, !, ?.
`<description>` (optional)	The description of the vault instance. The maximum character length is 150.
`<projectId>` (required)	The ID of the Google Account project which contains the Google Secret Manager.

Show me an example…

sudo ./edgecli vault create gcp iam-role "GCP-IAM" \
  --desc="GCP vault with IAM Role assigned to the Google Cloud Engine VM authentication" \
  --projectId="IAM_145"

Copy

sudo ./edgecli vault create gcp sa-json "<name>" \
  --desc="<description>" \
  --projectId="<projectId>" \
  --keyPath="<keyPath>"

Copy

./edgecli vault create gcp sa-json "<name>" \
  --desc="<description>" \
  --projectId="<projectId>" \
  --keyPath="<keyPath>"

Command	Description
`<name>` (required)	The name of the vault instance. It is required and it must be unique within an Edge site. For Kubernetes guidelines on the required naming conventions of the <name> parameter, go to Labels and Selectors. Note The name can only contain alphanumeric, dash (-), underscore ( _ ), or period (.) characters. The name cannot include white spaces or special characters such as /, !, ?.
`<description>` (optional)	The description of the vault instance. The maximum character length is 150.
`<projectId>` (required)	The ID of the Google Account project which contains the Google Secret Manager.
`<keyPath>` (required)	The file containing the Client Private Key.

Show me an example…

sudo ./edgecli vault create gcp sa-json "GCP-JSON" \
  --desc="GCP Secret Manager vault with JSON Key authentication" \
  --projectId="JSON_145" \
  --keyPath="~/GCP/vault/edge-site.json"

Copy

sudo ./edgecli vault create gcp sa-p12 "<name>" \
  --desc="<description>" \
  --projectId="<projectId>" \
  --keyPath="<keyPath>" \
  --keyPassword="<keyPassword>" \
  --emailAddress="<emailAddress>"

Copy

./edgecli vault create gcp sa-p12 "<name>" \
  --desc="<description>" \
  --projectId="<projectId>" \
  --keyPath="<keyPath>" \
  --keyPassword="<keyPassword>" \
  --emailAddress="<emailAddress>"

Command	Description
`<name>` (required)	The name of the vault instance. It is required and it must be unique within an Edge site. For Kubernetes guidelines on the required naming conventions of the <name> parameter, go to Labels and Selectors. Note The name can only contain alphanumeric, dash (-), underscore ( _ ), or period (.) characters. The name cannot include white spaces or special characters such as /, !, ?.
`<description>` (optional)	The description of the vault instance. The maximum character length is 150.
`<projectId>` (required)	The ID of the Google Account project which contains the Google Secret Manager.
`<keyPath>` (required)	The file containing the Client Private Key.
`<keyPassword>`	The P12 password.
`<emailAddress>`	The Google Service Account email address.

Show me an example…

sudo ./edgecli vault create gcp sa-p12 "GCP-P12" \
  --desc="GCP Secret Manager vault with Service Account P12 Key authentication" \
  --projectId="P12_145" \
  --keyPath="/GCP/vault/edge-site.p12" \
  --keyPassword="GCP_edge_vault_password" \
  --emailAddress="[email protected]"

Your available vault integrations are visible on the Vaults tab of your Edge site.

Note If you need help using the Edge CLI, use the following help command:

Copy

sudo ./edgecli vault create "<vault>" "<authMethod>" -h

Copy

./edgecli vault create "<vault>" "<authMethod>" -h

What's next?

You can now set up an Edge connection with your Google Secret Manager .
You can retrieve and review the configuration details of your vault integrations.
You can edit your vault integration configuration.

Integrate your CyberArk Vault with your Edge site connections by adding a vault to your Edge site.

You can connect to your CyberArk Vault using the following authentication methods:

mTLS
allow-list

Prerequisites

Ensure that your environment uses the latest user interface.
You installed your Edge site.
You have a global role that has the Manage Edge sites global permission.
You have access to the data source that will use the vault credentials.
You installed and configured the Edge CLI tool.
You have a CyberArk Vault .
Your CyberArk Vault is configured with either Allowed machines (allow-list) or Client certificates (mTLS).
You can administer CyberArk secrets. This includes the ability to do the following in your CyberArk Vault :
- Create
- Edit
- Delete
- Rotate credentials
Your CyberArk Credential Provider has GetPassword Web Service available in /AIMWebService.
If you use a --caPath, it must be in the X.509 format (PEM encoded).
If you use a --certPath, it must be in the X.509 format (PEM encoded).
If you use a --keyPath, it must be in the PKCS#8 format (PEM encoded).

Note There are a few limitations with the CyberArk Vault integration:

Forward proxies are not supported.
There must be a direct connection between your Edge site and CyberArk. You can only use scalar values. If your Edge site connection requires a Certificate or any other type of extra parameter, you can't use the CyberArk Vault integration.
Pass phrase protected certificates are not currently supported.

Steps

In the cluster where your Edge site is installed, use the Edge CLI tool to run the command for the mTLSallow-list authentication method.

Copy

sudo ./edgecli vault create cyber tls "<name>" \
  --desc "<description>" \
  --appId "<appId>" \
  --url "<url>" \
  --caPath "<caPath>" \
  --certPath "<certPath>" \
  --keyPath "<keyPath>"

Copy

./edgecli vault create cyber tls "<name>" \
  --desc "<description>" \
  --appId "<appId>" \
  --url "<url>" \
  --caPath "<caPath>" \
  --certPath "<certPath>" \
  --keyPath "<keyPath>"

Command	Description
`<name>` (required)	The name of the vault instance. It is required and it must be unique within an Edge site. For Kubernetes guidelines on the required naming conventions of the <name> parameter, go to Labels and Selectors. Note The name can only contain alphanumeric, dash (-), underscore ( _ ), or period (.) characters. The name cannot include white spaces or special characters such as /, !, ?.
`<description>` (optional)	The description of the vault instance. The maximum character length is 150.
`<appId>` (required)	The application ID configured on the CyberArk server.
`<url>` (required)	The URL of your CyberArk Vault .
`<caPath>` (required)	The file containing the Certificate Authority. If you use a `--caPath`, it must be in the X.509 format (PEM encoded).
`<certPath>` (required)	The file containing the Client Certificate. If you use a `--certPath`, it must be in the X.509 format (PEM encoded).
`<keyPath>` (required)	The file containing the Client Private Key. If you use a `--keyPath`, it must be in the PKCS#8 format (PEM encoded).

Note For more information about how to configure your CyberArk Vault integration, go to the following CyberArk resources:

Show me an example…

sudo ./edgecli vault create cyber tls "Edge CyberArk Vault mTLS" \
  --desc "CyberArk vault with mTLS authentication." \
  --appId "edge" \
  --url "https://edge-cyberark-server.example.com" \
  --caPath "./certs/ca.crt" \
  --certPath "./certs/aimws.crt" \
  --keyPath "./certs/aimws-pkcs8.key"

Copy

sudo ./edgecli vault create cyber allow-list "<name>" \
  --desc "<description>" \
  --appId "<appId>" \
  --url "<url>" \
  --caPath "<caPath>"

Copy

./edgecli vault create cyber allow-list "<name>" \
  --desc "<description>" \
  --appId "<appId>" \
  --url "<url>" \
  --caPath "<caPath>"

Command	Description
`<name>` (required)	The name of the vault instance. It is required and it must be unique within an Edge site. For Kubernetes guidelines on the required naming conventions of the <name> parameter, go to Labels and Selectors. Note The name can only contain alphanumeric, dash (-), underscore ( _ ), or period (.) characters. The name cannot include white spaces or special characters such as /, !, ?.
`<description>` (optional)	The description of the vault instance.
`<appId>` (required)	The application ID configured on the CyberArk server.
`<url>` (required)	The URL of your CyberArk Vault .
`<caPath>` (required)	The file containing the Certificate Authority. If you use a `--caPath`, it must be in the X.509 format (PEM encoded).

Note For more information about how to configure your CyberArk Vault integration, go to the following CyberArk resources:

Show me an example…

sudo ./edgecli vault create cyber allow-list "Edge CyberArk allowlist" \
--desc "CyberArk vault with allowlist authentication." \
--appId "edge" \
--url "https://edge-cyberark-server.example.com" \
--caPath "./certs/ca.crt"

Your available vault integrations are visible on the Vaults tab of your Edge site.

Note If you need help using the Edge CLI, use the following help command:

Copy

sudo ./edgecli vault create "<vault>" "<authMethod>" -h

Copy

./edgecli vault create "<vault>" "<authMethod>" -h

What's next?

You can now set up an Edge connection with your CyberArk Vault .
You can retrieve and review the configuration details of your vault integrations.
You can edit your vault integration configuration.

Integrate your HashiCorp Vault with your Edge site connections by adding a vault to your Edge site.

Prerequisites

Ensure that your environment uses the latest user interface.
You installed your Edge site.
You have a global role that has the Manage Edge sites global permission.
You have access to the data source that will use the vault credentials.
You installed and configured the Edge CLI tool.
You have a HashiCorp Vault.
You or another user can administer HashiCorp Vault secrets. This includes the ability to do the following in your HashiCorp Vault:
- Create
- Edit
- Delete
- Rotate credentials
You or another user have read credentials to the Authentication method and the HashiCorp Vault secret engine.
If you use a --caPath, it must be in the X.509 format (PEM encoded).
If you use a --certPath, it must be in the X.509 format (PEM encoded).
If you use a --keyPath, it must be in the PKCS#8 format (PEM encoded).

Note There are a few limitations with the HashiCorp Vault integration:

Forward proxies are not supported for HashiCorp Vault integrations. You must have a direct connection to your HashiCorp Vault.
HashiCorp Vault passwords are formatted as a map structure, in key/value pairs, for the two supported database engines.
- Key Value V2 secrets engine: A Field value is supplied to extract the value from the map structure for a scalar secret value.
- Database secrets engine: A pair of fields is available: username and password. These key names are fixed.
Only two authorization engines are currently supported:
- User-pass
- TLS

Steps

In the cluster where your Edge site is installed, use the Edge CLI tool to run the command for the username and passwordTLS authentication method:

Copy

sudo ./edgecli vault create hashicorp user-pass "<name>" \
  --desc "<description>" \
  --user "<username>" \
  --pass "<password>" \
  --caPath "<caPath>" \
  --url "<url>"
  --vaultNamespace "<vaultNamespace>"

Copy

./edgecli vault create hashicorp user-pass "<name>" \
  --desc "<description>" \
  --user "<username>" \
  --pass "<password>" \
  --caPath "<caPath>" \
  --url "<url>"
  --vaultNamespace "<vaultNamespace>"

Command	Description
`<name>` (required)	The name of the vault instance. It is required and it must be unique within an Edge site. For Kubernetes guidelines on the required naming conventions of the `<name>` parameter, go to Labels and Selectors. Note The name can only contain alphanumeric, dash (-), underscore ( _ ), or period (.) characters. The name cannot include white spaces or special characters such as /, !, ?.
`<description>` (optional)	The description of the vault instance. The maximum character length is 150.
`<user>` (required)	The username for your vault.
`<pass>` (required)	The password for your vault.
`<caPath>` (optional)	The file containing the Certificate Authority. If you use `--caPath` it must be in the PKCS#8 format. Note A `--caPath` file is optionally included for the creation of the authentication endpoint. It will not be required if the HTTP endpoint is used for the Username/Password authentication. The HTTP endpoint is used for the Username/Password authentication.
`<url>` (required)	The URL of the HashiCorp Vault.
`<vaultNamespace>` (optional)	A unique namespace in your vault.

Show me an example…

sudo ./edgecli vault create hashicorp user-pass "Hasicorp-Vault-Username-Password-AuthN" \
  --desc "HashiCorp vault with user-pass authentication." \
  --user "my-edge-site" \
  --pass "EdgePass123" \
  --caPath "~/hashicorp/vault/ca.pem" \
  --url "https://hashicorp-vault.edge.collibra/" \
  --vaultNamespace "HashiCorp vault 45"

Copy

sudo ./edgecli vault create hashicorp tls "<name>" \
  --authName "<authName>"
  --desc "<description>" \
  --caPath "<caPath>" \
  --certPath "<certPath>" \
  --keyPath "<keyPath>" \
  --url "<url>"
  --vaultNamespace "<vaultNamespace>"

Copy

./edgecli vault create hashicorp tls "<name>" \
  --authName "<authName>"
  --desc "<description>" \
  --caPath "<caPath>" \
  --certPath "<certPath>" \
  --keyPath "<keyPath>" \
  --url "<url>"
  --vaultNamespace "<vaultNamespace>"

Command	Description
`<name>` (required)	The name of the vault instance. It is required and it must be unique within an Edge site. For Kubernetes guidelines on the required naming conventions of the `<name>` parameter, go to Labels and Selectors. Note The name can only contain alphanumeric, dash (-), underscore ( _ ), or period (.) characters. The name cannot include white spaces or special characters such as /, !, ?.
`<authName>` (required)	The name of the HashiCorp Vault endpoint.
`<description>` (optional)	The description of the vault instance. The maximum character length is 150.
`<caPath>` (optional)	The file containing the Certificate Authority. If you use `--caPath` it must be in the PKCS#8 format. Note A `--caPath` file is optionally included for the creation of the authentication endpoint. It will not be required if the HTTPS certificate used for the SSL/TLS endpoint termination has a certificate chain supplied and the root certificate is in a Java trust store.
`<certPath>` (required)	The file containing the Client Certificate.
`<keyPath>` (required)	The file containing the Client Private Key.
`<url>` (required)	The URL of the HashiCorp Vault.
`<vaultNamespace>` (optional)	A unique namespace in your vault.

Show me an example…

sudo ./edgecli vault create hashicorp tls "tls-vault-auth" \
  --authName "tls-vault-auth" \"
  --desc "HashiCorp vault with tls authentication." \
  --caPath "~/hashicorp/vault/ca.pem" \
  --certPath "~/hashicorp/vault/edge-site.crt" \
  --keyPath "~/hashicorp/vault/edge-site.key" \
  --url "https://hashicorp-vault.edge.collibra/"
  --vaultNamespace "HashiCorp vault 45"

Your available vault integrations are visible on the Vaults tab of your Edge site.

Note If you need help using the Edge CLI, use the following help command:

Copy

sudo ./edgecli vault create "<vault>" "<authMethod>" -h

Copy

./edgecli vault create "<vault>" "<authMethod>" -h

What's next?

You can now set up an Edge connection with your HashiCorp Vault .
You can retrieve and review the configuration details of your vault integrations.
You can edit your vault integration configuration.

Integrate your Azure Key Vault with your Edge site connections by adding a vault to your Edge site.

You can connect to your Azure Key Vault using the following authentication methods:

Managed Identity assigned to Azure Virtual Machine
Service Principal Secret
Service Principal with PEM certificate
Service Principal with PFX certificate

Prerequisites

Ensure that your environment uses the latest user interface.
You installed your Edge site.
- In order to use the Managed Identity assigned to Azure Virtual Machine authentication method, you must install your Edge site inside of the Azure VM.
You have a global role that has the Manage Edge sites global permission.
You have access to the data source that will use the vault credentials.
You installed and configured the Edge CLI tool.
You have an Azure Key Vault.
You have the following Azure Key Vault roles or permissions:
- If you use Access Policies, you must have the Get and List Secret permissions.
- If you use Access Control (IAM), you must have the Key Vault Secrets User role, or a role with similar permissions.
You generated a client secret for the Azure Service Principal.
You generated a PEM certificate for the Azure Service Principal.
You generated a PFX certificate for the Azure Service Principal.
You assigned the managed identity to the Azure VM.
You created secrets in your Azure Key Vault.

Note There are a few limitations with the Azure Key Vault integration:

Forward proxies are not supported for Azure Key Vault integrations. You must have a direct connection to your Azure Key Vault.
Only scalar values are accepted for the Azure Key Vault. Each secret needs to resolve a single plain value or file.
Only the latest version of secrets can be accessed by your Edge site. You cannot set up and choose from different secret versions.

Steps

Copy

sudo ./edgecli vault create azure managed-identity "<name>" \
  --desc "<description>" \
  --dnsSuffix "<dnsSuffix>"

Copy

./edgecli vault create azure managed-identity "<name>" \
  --desc "<description>" \
  --dnsSuffix "<dnsSuffix>"

Command	Description
`<name>` (required)	The name of the vault instance. It is required and it must be unique within an Edge site. For Kubernetes guidelines on the required naming conventions of the <name> parameter, go to Labels and Selectors. Note The name can only contain alphanumeric, dash (-), underscore ( _ ), or period (.) characters. The name cannot include white spaces or special characters such as /, !, ?.
`<description>` (optional)	The description of the vault instance. The maximum character length is 150.
`<dnsSuffix>`	The data-plane endpoint for your vault. Note `<dnsSuffix>` is required if you use a private version of Azure for security purposes. For example, for FedRAMP, you would need to specify the Azure US Government DNS suffix: `vault.usgovcloudapi.net`. Otherwise, Edge uses the default value: `.vault.azure.net`.

Show me an example…

sudo ./edgecli vault create azure managed-identity "Azure-managed-identity" \
  --desc "Azure Key vault with managed identity authentication." 
  --dnsSuffix "vault.azure.net"

Copy

sudo ./edgecli vault create azure sp-secret "<name>" \
  --desc "<description>" \
  --dnsSuffix "<dnsSuffix>" \
  --tenantId "<tenantId>" \
  --clientId "<clientId>" \
  --clientSecret "<clientSecret>"

Copy

./edgecli vault create azure sp-secret "<name>" \
  --desc "<description>" \
  --dnsSuffix "<dnsSuffix>" \
  --tenantId "<tenantId>" \
  --clientId "<clientId>" \
  --clientSecret "<clientSecret>"

Command	Description
`<name>` (required)	The name of the vault instance. It is required and it must be unique within an Edge site. For Kubernetes guidelines on the required naming conventions of the <name> parameter, go to Labels and Selectors. Note The name can only contain alphanumeric, dash (-), underscore ( _ ), or period (.) characters. The name cannot include white spaces or special characters such as /, !, ?.
`<description>` (optional)	The description of the vault instance. The maximum character length is 150.
`<dnsSuffix>`	The data-plane endpoint for your vault. Note `<dnsSuffix>` is required if you use a private version of Azure for security purposes. For example, for FedRAMP, you would need to specify the Azure US Government DNS suffix: `vault.usgovcloudapi.net`. Otherwise, Edge uses the default value: `.vault.azure.net`.
`<tenantId>` (required)	The unique identifier of the Azure AD instance that the Azure Key Vault belongs to.
`<clientId>` (required)	The identifier of the service principal client.
`<clientSecret>` (required)	The secret of the service principal client.

Show me an example…

sudo ./edgecli vault create azure sp-secret "Azure-service-principal" \
  --desc "Azure Key vault with service principal secret authentication." \
  --dnsSuffix "vault.azure.net" \
  --tenantId "165" \
  --clientId "AZ_22" \
  --clientSecret "Secret123"

Copy

sudo ./edgecli vault create azure sp-pem "<name>" \
  --desc "<description>" \
  --dnsSuffix "<dnsSuffix>" \
  --tenantId "<tenantId>" \
  --clientId "<clientId>" \
  --certPath "<certPath>"

Copy

./edgecli vault create azure sp-pem "<name>" \
  --desc "<description>" \
  --dnsSuffix "<dnsSuffix>" \
  --tenantId "<tenantId>" \
  --clientId "<clientId>" \
  --certPath "<certPath>"

Command	Description
`<name>` (required)	The name of the vault instance. It is required and it must be unique within an Edge site. For Kubernetes guidelines on the required naming conventions of the <name> parameter, go to Labels and Selectors. Note The name can only contain alphanumeric, dash (-), underscore ( _ ), or period (.) characters. The name cannot include white spaces or special characters such as /, !, ?.
`<description>` (optional)	The description of the vault instance. The maximum character length is 150.
`<dnsSuffix>`	The data-plane endpoint for your vault. Note `<dnsSuffix>` is required if you use a private version of Azure for security purposes. For example, for FedRAMP, you would need to specify the Azure US Government DNS suffix: `vault.usgovcloudapi.net`. Otherwise, Edge uses the default value: `.vault.azure.net`.
`<tenantId>` (required)	The unique identifier of the Azure AD instance that the Azure Key Vault belongs to.
`<clientId>` (required)	The identifier of the service principal client.
`<certPath>` (required)	The file containing the Client Certificate.

Show me an example…

sudo ./edgecli vault create azure sp-secret "Azure-service-principal-PEM" \
  --desc "Azure Key vault with service principal with PEM cert authentication." \
  --dnsSuffix "vault.azure.net" \
  --tenantId "165" \
  --clientId "AZ_22" \
  --certPath "~/azurekey/vault/edge-site.pem"

Copy

sudo ./edgecli vault create azure sp-pfx "<name>" \
  --desc "<description>" \
  --dnsSuffix "<dnsSuffix>" \
  --tenantId "<tenantId>" \
  --clientId "<clientId>" \
  --certPath "<certPath>" \
  --certPassword "<certPassword>"

Copy

./edgecli vault create azure sp-pfx "<name>" \
  --desc "<description>" \
  --dnsSuffix "<dnsSuffix>" \
  --tenantId "<tenantId>" \
  --clientId "<clientId>" \
  --certPath "<certPath>" \
  --certPassword "<certPassword>"

Command	Description
`<name>` (required)	The name of the vault instance. It is required and it must be unique within an Edge site. For Kubernetes guidelines on the required naming conventions of the <name> parameter, go to Labels and Selectors. Note The name can only contain alphanumeric, dash (-), underscore ( _ ), or period (.) characters. The name cannot include white spaces or special characters such as /, !, ?.
`<description>` (optional)	The description of the vault instance. The maximum character length is 150.
`<dnsSuffix>`	The data-plane endpoint for your vault. Note `<dnsSuffix>` is required if you use a private version of Azure for security purposes. For example, for FedRAMP, you would need to specify the Azure US Government DNS suffix: `vault.usgovcloudapi.net`. Otherwise, Edge uses the default value: `.vault.azure.net`.
`<tenantId>` (required)	The unique identifier of the Azure AD instance that the Azure Key Vault belongs to.
`<clientId>` (required)	The identifier of the service principal client.
`<certPath>` (required)	The file containing the Client Certificate.
`<certPassword>` (required)	The password used to protect the PFX certificate.

Show me an example…

sudo ./edgecli vault create azure sp-secret "Azure-service-principal-PFX" \
  --desc "Azure Key vault with service principal with PFX cert authentication." \
  --dnsSuffix "vault.azure.net" \
  --tenantId "165" \
  --clientId "AZ_22" \
  --certPath "~/azurekey/vault/edge-site.pfx" \
  --certPassword "AZ_PFX_password1"

Your available vault integrations are visible on the Vaults tab of your Edge site.

Note If you need help using the Edge CLI, use the following help command:

Copy

sudo ./edgecli vault create "<vault>" "<authMethod>" -h

Copy

./edgecli vault create "<vault>" "<authMethod>" -h

What's next?

You can now set up an Edge connection with your Azure Key Vault .
You can retrieve and review the configuration details of your vault integrations.
You can edit your vault integration configuration.

Integrate your AWS Secrets Manager with your Edge site connections by adding a Vault to your Edge site.

Note

Edge sites already running on AWS have Instance Profiles and the Assume role.
Edge sites running outside of AWS can connect to the Secrets Manager by using an access key.

You can connect to your AWS Secrets Manager using the following authentication methods:

IAM Access Key
Instance Profile
Assume Role
- Assume Role is similar to Instance Profile, but allows you to narrow down the access to your vault to a singe role.

Prerequisites

Ensure that your environment uses the latest user interface.
You installed your Edge site.
- If you are using the Instance Profile authentication method, your Edge site must be running on an EC2 or EKS instance assigned to an Instance Profile that has access to the AWS Secrets Manager you want to connect to.
- If you are using the Assume Role authentication method, your Edge site must be running on an EC2 or EKS instance assigned to an Instance Profile that with access to role that has read access to the AWS Secrets Manager you want to connect to.
You have a global role that has the Manage Edge sites global permission.
You have access to the data source that will use the vault credentials.
You installed and configured the Edge CLI tool.
Your Edge site has network access to the AWS Secrets Manager endpoints.
You have a AWS Secrets Manager.
If your AWS Secret Manager uses either the Assume Role or Instance Profile authentication method, IMDSv1 or IMDSv2 must be enabled.
- If you have IMDSv2 enabled, you must run the following command from an AWS Secrets Manager admin account to set the hop limit to 2:
  Copy
```
aws ec2 modify-instance-metadata-options --instance-id <instance-id> --http-tokens required --http-endpoint enabled --http-put-response-hop-limit 2
```
You created secrets in your AWS Secrets Manager.
- If you are using the IAM Access Key authentication method, you must create IAM credentials with read access to the AWS Secrets Manager where your Edge site secrets will be stored.

Note Forward proxies are not supported for AWS Secrets Manager integrations. You must have a direct connection to your AWS Secrets Manager.

Steps

In the cluster where your Edge site is installed, use the Edge CLI tool to run the command for the IAM access keyinstance profileassume role authentication method.

Copy

sudo ./edgecli vault create aws key-secret "<name>" \
  --desc="<description>" \
  --region="<region>" \
  --endpointOverride="<endpointOverride>" \
  --accessKeyId="<accessKeyId>" \
  --accessKey="<accessKey>"

Copy

./edgecli vault create aws key-secret "<name>" \
  --desc="<description>" \
  --region="<region>" \
  --endpointOverride="<endpointOverride>" \
  --accessKeyId="<accessKeyId>" \
  --accessKey="<accessKey>"

Command	Description
`<name>` (required)	The name of the vault instance. It is required and it must be unique within an Edge site. For Kubernetes guidelines on the required naming conventions of the <name> parameter, go to Labels and Selectors. Note The name can only contain alphanumeric, dash (-), underscore ( _ ), or period (.) characters. The name cannot include white spaces or special characters such as /, !, ?.
`<description>` (optional)	The description of the vault instance. The maximum character length is 150.
`<region>`	The region of the AWS Secrets Manager you want to use. Note Region is optional if your Edge site and AWS Secrets Manager are both located in the same AWS region. Region is required if: You are using `<endpointOverride>`. Your Edge site is on k3s and running in AWS. Your Edge site is running in a different region than the AWS Secrets Manager you want to connect to.
`<endpointOverride>`	The URL of the entry point for your AWS Secrets Manager vault. Note `<endpointOverride>` is required if you use a private version of AWS for security purposes. For example, for FIPS, you would need to specify the FIPS endpoint: `<protocol>"://://"<service-code>"-fips."<region>".amazonaws.com`. Otherwise, Edge will use the default regional value: `"<protocol>"://"<service-code>"."<region-code>".amazonaws.com`
`<accessKeyId>` (required)	The ID of the IAM key you want to authenticate with.
`<accessKey>` (required)	The IAM key you want to authenticate with.

Show me an example…

sudo ./edgecli vault create aws key-secret "AWS-IAM" \
  --desc="AWS vault with IAM Access Key authentication." \
  --region="eu-west-1" \
  --endpointOverride="http://my-secret-vault.aws.com" \
  --accessKeyId="1234" \
  --accessKey="abcd"

Copy

sudo ./edgecli vault create aws instance-profile "<name>" \
  --desc="<description>" \
  --region="<region>" \
  --endpointOverride="<endpointOverride>"

Copy

./edgecli vault create aws instance-profile "<name>" \
  --desc="<description>" \
  --region="<region>" \
  --endpointOverride="<endpointOverride>"

Command	Description
`<name>` (required)	The name of the vault instance. It is required and it must be unique within an Edge site. For Kubernetes guidelines on the required naming conventions of the <name> parameter, go to Labels and Selectors. Note The name can only contain alphanumeric, dash (-), underscore ( _ ), or period (.) characters. The name cannot include white spaces or special characters such as /, !, ?.
`<description>` (optional)	The description of the vault instance. The maximum character length is 150.
`<region>`	The region of the AWS Secrets Manager you want to use. Note Region is optional if your Edge site and AWS Secrets Manager are both located in the same AWS region. Region is required if: You are using `<endpointOverride>`. Your Edge site is on k3s and running in AWS. Your Edge site is running in a different region than the AWS Secrets Manager you want to connect to.
`<endpointOverride>`	The URL of the entry point for your AWS Secrets Manager. Note `<endpointOverride>` is required if you use a private version of AWS for security purposes. For example, for FIPS, you would need to specify the FIPS endpoint: `<protocol>"://://"<service-code>"-fips."<region>".amazonaws.com`. Otherwise, Edge will use the default regional value: `"<protocol>"://"<service-code>"."<region-code>".amazonaws.com`

Show me an example…

sudo ./edgecli vault create aws instance-profile "AWS-Instance" \
  --desc="AWS vault with Instant Profile authentication" \
  --region="eu-west-1" \
  --endpointOverride="http://my-secret-vault.aws.com"

Copy

sudo ./edgecli vault create aws assume-role "<name>" \
  --desc="<description>" \
  --roleArn="<roleArn>"
  --roleSessionName="<roleSessionName>"
  --region="<region>"\
  --endpointOverride="<endpointOverride>"

Copy

./edgecli vault create aws assume-role "<name>" \
  --desc="<description>" \
  --roleArn="<roleArn>"
  --roleSessionName="<roleSessionName>"
  --region="<region>"\
  --endpointOverride="<endpointOverride>"

Command	Description
`<name>` (required)	The name of the vault instance. It is required and it must be unique within an Edge site. For Kubernetes guidelines on the required naming conventions of the <name> parameter, go to Labels and Selectors. Note The name can only contain alphanumeric, dash (-), underscore ( _ ), or period (.) characters. The name cannot include white spaces or special characters such as /, !, ?.
`<description>` (optional)	The description of the vault instance. The maximum character length is 150.
`<roleArn>` (required)	The Amazon Resource name of the role you want your Edge site to assume when accessing the AWS Secrets Manager secrets. Note In order for your Edge site to successfully assume this specified role, the Instance Profile role that is attached to the EKS cluster must be trusted by the target role.
`<roleSessionName>` (optional)	The name of the session you want this role to appear as in AWS security logs.
`<region>`	The region of the AWS Secrets Manager you want to use. Note Region is optional if your Edge site and AWS Secrets Manager are both located in the same AWS region. Region is required if: You are using `<endpointOverride>`. Your Edge site is on k3s and running in AWS. Your Edge site is running in a different region than the AWS Secrets Manager you want to connect to.
`<endpointOverride>`	The URL of the entry point for your AWS Secrets Manager. Note `<endpointOverride>` is required if you use a private version of AWS for security purposes. For example, for FIPS, you would need to specify the FIPS endpoint: `<protocol>"://://"<service-code>"-fips."<region>".amazonaws.com`. Otherwise, Edge will use the default regional value: `"<protocol>"://"<service-code>"."<region-code>".amazonaws.com`

Show me an example…

sudo ./edgecli vault create aws instance-profile "AWS-Assume" \
  --desc="AWS vault with Assume Role authentication" \
  --roleArn="edge-session"
  --roleSessionName="edge-session"
  --region="eu-west-1" \
  --endpointOverride="http://my-secret-vault.aws.com"

Your available vault integrations are visible on the Vaults tab of your Edge site.

Note If you need help using the Edge CLI, use the following help command:

Copy

sudo ./edgecli vault create "<vault>" "<authMethod>" -h

Copy

./edgecli vault create "<vault>" "<authMethod>" -h

What's next?

You can now set up an Edge connection with your AWS Secrets Manager .
You can retrieve and review the configuration details of your vault integrations.
You can edit your vault integration configuration.

Integrate your Google Secret Manager with your Edge site connections by adding a vault to your Edge site.

You can connect to your Google Secret Manager using the following authentication methods:

IAM Role assigned to the Google Cloud Engine VM
Service Account JSON Key
Service Account P12 Key

Prerequisites

Ensure that your environment uses the latest user interface.
You installed your Edge site.
- In order to use the IAM Role assigned to the Google Cloud Engine VM authentication method, you must install your Edge site inside of the Google Cloud Engine VM.
You have a global role that has the Manage Edge sites global permission.
You have access to the data source that will use the vault credentials.
You installed and configured the Edge CLI tool.
You have a Google Cloud account.
Your Google Secret Manager account must have the following permissions:
- iam.serviceAccounts.getAccessToken
- resourcemanager.projects.get
- secretmanager.secrets.get
- secretmanager.secrets.getIamPolicy
- secretmanager.secrets.list
- secretmanager.versions.access
- secretmanager.versions.get
- secretmanager.versions.list
You assigned a Google Service Account to the Google Cloud Engine VM where your Edge site secrets will be stored.
Your Edge site has network access to the Google Secret Manager endpoints.
You generated a JSON key for the Google Service Account.
You generated P12 key for Google Service Account.
Note P12 is a deprecated key type for backwards compatibility. The steps provided in Google's documentation about creating access credentials are intended for JSON. You can still follow the same steps for P12, with the only difference being the selection of the P12 Key Type instead of JSON.
You created secrets in your Google Secret Manager.

Note There are a few limitations with the Google Secret Manager integration:

Forward proxies are not supported for Google Secret Manager integrations. You must have a direct connection to your Google Secret Manager.
Only scalar values are accepted for the Google Secret Manager. Each secret needs to resolve a single plain value or file.
Only the latest version of secrets can be accessed by your Edge site. You cannot set up and choose from different secret versions.

Required permissions

You have access to both Edge management and your connections data sources that will use the vault credentials.

Steps

In the cluster where your Edge site is installed, use the Edge CLI tool to run the command for the IAM role assigned to the Google Cloud Engine VMJSON keyP12 key authentication method.

Copy

sudo ./edgecli vault create gcp iam-role "<name>" \
  --desc="<description>" \
  --projectId="<projectId>"

Copy

./edgecli vault create gcp iam-role "<name>" \
  --desc="<description>" \
  --projectId="<projectId>"

Command	Description
`<name>` (required)	The name of the vault instance. It is required and it must be unique within an Edge site. For Kubernetes guidelines on the required naming conventions of the <name> parameter, go to Labels and Selectors. Note The name can only contain alphanumeric, dash (-), underscore ( _ ), or period (.) characters. The name cannot include white spaces or special characters such as /, !, ?.
`<description>` (optional)	The description of the vault instance. The maximum character length is 150.
`<projectId>` (required)	The ID of the Google Account project which contains the Google Secret Manager.

Show me an example…

sudo ./edgecli vault create gcp iam-role "GCP-IAM" \
  --desc="GCP vault with IAM Role assigned to the Google Cloud Engine VM authentication" \
  --projectId="IAM_145"

Copy

sudo ./edgecli vault create gcp sa-json "<name>" \
  --desc="<description>" \
  --projectId="<projectId>" \
  --keyPath="<keyPath>"

Copy

./edgecli vault create gcp sa-json "<name>" \
  --desc="<description>" \
  --projectId="<projectId>" \
  --keyPath="<keyPath>"

Command	Description
`<name>` (required)	The name of the vault instance. It is required and it must be unique within an Edge site. For Kubernetes guidelines on the required naming conventions of the <name> parameter, go to Labels and Selectors. Note The name can only contain alphanumeric, dash (-), underscore ( _ ), or period (.) characters. The name cannot include white spaces or special characters such as /, !, ?.
`<description>` (optional)	The description of the vault instance. The maximum character length is 150.
`<projectId>` (required)	The ID of the Google Account project which contains the Google Secret Manager.
`<keyPath>` (required)	The file containing the Client Private Key.

Show me an example…

sudo ./edgecli vault create gcp sa-json "GCP-JSON" \
  --desc="GCP Secret Manager vault with JSON Key authentication" \
  --projectId="JSON_145" \
  --keyPath="~/GCP/vault/edge-site.json"

Copy

sudo ./edgecli vault create gcp sa-p12 "<name>" \
  --desc="<description>" \
  --projectId="<projectId>" \
  --keyPath="<keyPath>" \
  --keyPassword="<keyPassword>" \
  --emailAddress="<emailAddress>"

Copy

./edgecli vault create gcp sa-p12 "<name>" \
  --desc="<description>" \
  --projectId="<projectId>" \
  --keyPath="<keyPath>" \
  --keyPassword="<keyPassword>" \
  --emailAddress="<emailAddress>"

Command	Description
`<name>` (required)	The name of the vault instance. It is required and it must be unique within an Edge site. For Kubernetes guidelines on the required naming conventions of the <name> parameter, go to Labels and Selectors. Note The name can only contain alphanumeric, dash (-), underscore ( _ ), or period (.) characters. The name cannot include white spaces or special characters such as /, !, ?.
`<description>` (optional)	The description of the vault instance. The maximum character length is 150.
`<projectId>` (required)	The ID of the Google Account project which contains the Google Secret Manager.
`<keyPath>` (required)	The file containing the Client Private Key.
`<keyPassword>`	The P12 password.
`<emailAddress>`	The Google Service Account email address.

Show me an example…

sudo ./edgecli vault create gcp sa-p12 "GCP-P12" \
  --desc="GCP Secret Manager vault with Service Account P12 Key authentication" \
  --projectId="P12_145" \
  --keyPath="/GCP/vault/edge-site.p12" \
  --keyPassword="GCP_edge_vault_password" \
  --emailAddress="[email protected]"

Your available vault integrations are visible on the Vaults tab of your Edge site.

Note If you need help using the Edge CLI, use the following help command:

Copy

sudo ./edgecli vault create "<vault>" "<authMethod>" -h

Copy

./edgecli vault create "<vault>" "<authMethod>" -h

What's next?

You can now set up an Edge connection with your Google Secret Manager .
You can retrieve and review the configuration details of your vault integrations.
You can edit your vault integration configuration.