設定

此頁面提供有關 KES 用戶端和 KES 伺服器的 KES 設定選項的資訊。

KES 客戶端

作為基本的標準設定,KES 用戶端需要知道

  • KES 伺服器端點
  • KES 客戶端自己的用戶端憑證
  • 對應於用戶端憑證的私密金鑰

您可以透過不同的方式提供這些值,例如透過命令列上的環境變數或透過軟體開發套件。

命令列

從命令列中,使用下列環境變數來定義三個基本設定。

  • KES 伺服器端點
    export KES_SERVER=https://127.0.0.1:7373
    
  • 用戶端 X.509 憑證
    export KES_CLIENT_CERT=$HOME/root.cert
    
  • 對應於憑證中嵌入的公開金鑰的私密金鑰
    export KES_CLIENT_KEY=$HOME/root.key
    

軟體開發套件

當使用軟體開發套件時,請提供伺服器端點並擷取用戶端的私密金鑰和憑證

package main

import (
	"crypto/tls"
	"log"

	"github.com/minio/kes"
)

func main() {
	const (
		endpoint = "https://127.0.0.1:7373"
		certFile = "./root.cert"
		keyFile  = "./root.key"
	)
	certificate, err := tls.LoadX509KeyPair(certFile, keyFile)
	if err != nil {
		log.Fatalln(err)
	}

	client := kes.NewClient(endpoint, certificate)

	// now use the client to perform operations...
	_ = client
}

KES 伺服器

KES 伺服器需要四項資訊作為基本設定:

  1. TCP 位址(即 IP 位址和連接埠),用於監聽傳入的請求
  2. X.509 憑證
  3. 對應的私密金鑰
  4. 根身分。

您可以使用命令列 (CLI) 旗標或設定檔來指定這些參數。如果您在命令列和設定檔中都設定了參數,則以命令列設定為優先。

如果您沒有指定 TCP 位址,KES 伺服器會在連接埠 7373 上監聽所有可用的網路介面。

以下命令會啟動 KES 伺服器,監聽所有網路介面上連接埠 7373 的連線,並使用 X.509 TLS 憑證 server.crt、對應的私密金鑰 server.key,以及從環境變數 $ROOT_IDENTITY 取得的根身分。

kes server --cert server.crt --key private.key --root $ROOT_IDENTITY

設定檔

使用 YAML 設定檔來自訂 KES 伺服器的行為。

設定檔分為數個區段:

  • 包含伺服器位址和根身分的通用伺服器設定區段。
  • 指定伺服器金鑰/憑證和 TLS Proxy 設定的 TLS 區段
  • 啟用或停用特定端點驗證的 API 區段
  • 控制誰可以執行各種 API 操作的 原則區段
  • 控制 KES 伺服器在記憶體中快取金鑰時間長度的 快取區段
  • 控制哪些日誌訊息寫入 STDOUTSTDERR日誌記錄區段
  • 指定在哪裡儲存和擷取金鑰的 KMS / 金鑰儲存區段

TLS 設定

使用 TLS 設定區段來指定 KES 伺服器的 X.509 憑證和對應的私密金鑰。

tls:
  cert: server.crt
  key:  server.key

(選用)也可以在此區段中設定 TLS Proxy。如需更多資訊,請參閱個別的TLS Proxy 頁面

API 設定

預設情況下,KES 要求所有 API 呼叫都必須使用有效的 TLS 憑證。您可以變更特定 API 端點的此行為,允許在沒有憑證的情況下向端點發出請求。

KES API 端點的預設行為應該適用於大多數情況。請僅針對特定需求自訂端點。

當您停用至少一個端點的驗證時,KES 將不再要求用戶端在呼叫任何 API 端點時必須使用憑證。但是,請求仍然必須包含憑證,KES 才能成功處理任何需要驗證的 API 端點呼叫。

此變更表示在至少設定了一個端點以停用驗證的 KES 伺服器上,用戶端在失敗時不會收到 TLS 錯誤,而是收到 HTTP 錯誤。

您可以停用下列 API 端點的驗證:

  • /v1/ready
  • /v1/status
  • /v1/metrics
  • /v1/api

例如,若要跳過允許準備探查和狀態檢查的端點的驗證,請將以下內容新增至設定檔:

api:
  /v1/ready:
    skip_auth: true
    timeout:   15s
  /v1/ready:
    skip_auth: false
    timeout:   15s

如需 KES API 的資訊,請參閱連結文字

快取設定

使用快取設定區段來指定 KES 伺服器應如何快取從外部 KMS 擷取的金鑰。

cache:
  expiry:
    any:    5m0s
    unused: 20s

您可以透過指定 any 快取金鑰或 unused 快取金鑰的不同到期值,來控制 KES 伺服器從外部 KMS 擷取金鑰的頻率。

例如,any: 5m0s 表示 KES 伺服器每 5 分鐘清除記憶體中的快取。unused: 20s 表示 KES 伺服器會從快取中移除在過去 20 秒內未使用的任何金鑰。

快取到期值的選擇是在安全性和效能之間的權衡。透過設定值 any: 1m0s,KES 伺服器必須比 any: 5m0s 的情況更頻繁地與外部 KMS 通訊 5 倍。但是,any: 1m0s 設定會減少 KES 伺服器在沒有外部 KMS 任何控制的情況下運作的時間。

以下值可能可以協助您做出決定。

安全性等級 any unused
寬鬆 5m0s 30s
中等 1m0s 20s
保守 30s 5s

日誌設定

使用日誌設定區段來指定哪些日誌事件會寫入 STDOUTSTDERR。KES 伺服器會區分錯誤和稽核日誌事件。預設情況下,伺服器會將錯誤事件寫入 STDERR,但不會將稽核事件記錄至 STDOUT

通常,錯誤事件表示發生了一些設定或操作錯誤。例如,當因為非預期的原因而無法從 KMS 擷取金鑰時,KES 伺服器會記錄錯誤事件。

當 KES 伺服器接受用戶端請求時,會產生稽核事件。稽核事件會描述請求-回應配對,並包含有關誰發出請求的資訊。

log:
  error: on  # To disable error logging to STDERR - explicitly set it to off
  audit: off # To enable audit logging to STDOUT - explicitly set it to on

log 區段控制將事件記錄到 STDOUTSTDERR。KES 伺服器也透過 API 提供稽核和錯誤日誌追蹤,並使用 /v1/log/audit/trace/v1/log/error/trace

具有足夠權限的用戶端可以隨時訂閱稽核或錯誤日誌。

原則設定

在原則設定區段中,您可以定義原則和基於身分的存取控制規則。原則區段可以包含任意多個原則定義。每個原則都必須有一個唯一的名稱,例如 my-policy。讓我們來看一個範例原則:

policy:
  my-policy:
    allow:
    - /v1/key/create/my-key
    - /v1/key/generate/my-key
    - /v1/key/decrypt/my-key
    deny:
    - /v1/key/*/my-key-internal

原則會使用其 API 允許和拒絕規則來明確允許 API 操作。每個規則都是一個 glob 模式。用戶端請求必須符合至少一個允許模式,且不符合任何拒絕模式。否則,伺服器會拒絕該請求。

KES 伺服器會依以下方式評估原則:

  1. 評估所有拒絕模式。如果任何拒絕模式符合,則會以 prohibited by policy 錯誤拒絕請求。
  2. 評估所有允許模式。如果至少有一個允許模式符合,則 KES 會接受請求。
  3. 如果沒有任何允許模式符合,則會以 prohibited by policy 錯誤拒絕請求。

不需要拒絕特定的 API 操作。而是僅將拒絕規則用於細微的存取控制。KES 伺服器會拒絕原則未明確允許的任何 API 操作。明確的拒絕規則優先於允許規則。

先前討論的原則 my-policy 授予對 /v1/key API 的存取權。特別是,該原則允許三個操作:creategeneratedecrypt。但是,只能使用金鑰 my-key。因此,my-policy 原則具有以下語意:

請求 回應 原因
/v1/key/create/my-key 允許 請求路徑符合第一個原則路徑
/v1/key/generate/my-key 允許 請求路徑符合第二個原則路徑
/v1/key/create/my-key2 拒絕 my-key2 不符合 my-key
/v1/key/delete/my-key 拒絕 delete 不符合 creategeneratedecrypt
/v1/policy/write/my-policy 拒絕 policy 不符合 key
/v0/key/create/my-key 拒絕 v0 不符合 v1

指定確切的請求路徑非常不彈性。因此,原則路徑是 glob 模式。讓我們調整 my-policy 原則如下:

policy:
  my-policy:
    allow:
    - /v1/key/create/my-key*
    - /v1/key/generate/my-key*
    - /v1/key/decrypt/my-key*
    - /v1/key/delete/my-key
    deny:
    - /v1/key/*/my-key-internal

現在,my-policy 原則將具有以下語意:

請求 回應 原因
/v1/key/create/my-key 允許 請求路徑符合第一個原則路徑
/v1/key/generate/my-key 允許 請求路徑符合第二個原則路徑
/v1/key/create/my-key2 允許 請求路徑符合第一個原則路徑
/v1/key/delete/my-key 允許 請求路徑符合第四個原則路徑
/v1/key/delete/my-key2 拒絕 delete/my-key2 不符合 delete/my-key (沒有 *)
/v1/key/decrypt/my-key-internal 拒絕 decrypt/my-key-internal 已明確拒絕

透過使用 glob 模式,原則相當彈性,但對於人類來說仍然容易閱讀。

例如:

  • /v1/key/create/*:允許建立具有任意名稱的金鑰。
  • /v1/key/*/my-key:允許對金鑰 my-key 執行所有金鑰 API 操作 (creategenerate、…)。
  • /v1/key/*/*:允許對任何金鑰執行所有金鑰 API 操作。

例如,在上述更新的政策範例中,拒絕規則 /v1/key/*/my-key-internal 會拒絕任何使用金鑰 my-key-internal 的 API 操作。

請注意,萬用字元 (*?) 僅適用於目前的路徑區段。 /v1/key/*/v1/key/*/* 並不相同。第一個規則允許任意金鑰 API 操作,但僅適用於空的金鑰名稱。第二個規則允許任意金鑰 API 操作,適用於任意金鑰。

如需更多詳細資訊,請參閱伺服器 API 頁面上的完整清單。

政策與身分

使用政策區段來定義哪個政策適用於哪個身分。身分可以從 X.509 憑證計算得出,如下所示

kes identity of <path-to-certificate-file>

您可以在政策區段中將一個或多個身分指派給一個政策。您可以用兩種方式指定身分

  • 插入身分本身
  • 指定環境變數名稱

如果您使用環境變數,KES 伺服器會在啟動時插入該值。

policy:
  my-policy:
    allow:
    - /v1/key/create/my-key
    - /v1/key/generate/my-key
    - /v1/key/decrypt/my-key
    identities:
    - 3ecfcdf38fcbe141ae26a1030f81e96b753365a46760ae6b578698a97c59fd22
    - ${MY_APP_IDENTITY}
您必須在啟動伺服器之前設定所有預期的環境變數。即使環境變數不存在或不包含「有效」身分,伺服器仍會啟動。

金鑰設定

使用金鑰設定區段宣告在 KES 伺服器開始接受請求之前應該存在的加密金鑰。

keys:
  - name: "my-key"
  - name: "my-key-2"

啟動時,KES 伺服器會確保指定的金鑰存在。KES 伺服器會嘗試在接受客戶端請求之前建立任何不存在的金鑰,如果無法建立金鑰則會退出。

KMS 設定

使用 KMS/金鑰儲存設定區段來指定 KES 伺服器儲存和提取主金鑰的位置。這應該是一個提供安全儲存元件或加密金鑰儲存的 KMS。但是,對於測試和開發,您可以將主金鑰儲存在記憶體中或檔案系統上。

如果您未在設定檔中指定 KMS/金鑰儲存,KES 伺服器會在記憶體中建立主金鑰。這僅適用於測試或開發設置,因為當您重新啟動伺服器時,所有主金鑰都會遺失。

若要建立持續性的測試或開發設置,請在設定檔中指定檔案系統金鑰儲存

keystore:
  fs:
    path: ./keys # The key store directory. Keys will be created inside ./keys/

對於生產環境設置,請使用由 KMS(例如 Hashicorp Vault)支援的安全金鑰儲存。

範例設定檔

下列 yaml 檔案提供帶有使用說明的範例設定檔。如需最新的範例檔案,請參閱 GitHub 儲存庫

# The config file version. Currently this field is optional but future
# KES versions will require it. The only valid value is "v1". 
version: v1

# The TCP address (ip:port) for the KES server to listen on.
address: 0.0.0.0:7373 # The pseudo address 0.0.0.0 refers to all network interfaces 

admin:
  # The admin identity identifies the public/private key pair
  # that can perform any API operation.
  # The admin account can be disabled by setting a value that
  # cannot match any public key - for example, "foobar" or "disabled".
  identity: c84cc9b91ae2399b043da7eca616048d4b4200edf2ff418d8af3835911db945d

# The TLS configuration for the KES server. A KES server
# accepts HTTP only over TLS (HTTPS). Therefore, a TLS
# private key and public certificate must be specified,
# either here as part of the config file or via CLI arguments.
tls:
  key:      ./server.key   # Path to the TLS private key
  cert:     ./server.cert  # Path to the TLS certificate
  password: ""             # An optional password to decrypt the TLS private key

  # Specify how/whether the KES server verifies certificates presented
  # by clients. Valid values are "on" and "off". Defaults to off, which
  # is recommended for most use cases.
  auth:     ""
  
  # An optional path to a file or directory containing X.509 certificate(s).
  # If set, the certificate(s) get added to the list of CA certificates for
  # verifying the mTLS certificates sent by the KES clients.
  #
  # If empty, the system root CAs will be used.
  ca:       ""        

  # The TLS proxy configuration. A TLS proxy, like nginx, sits in
  # between a KES client and the KES server and usually acts as a
  # load balancer or common endpoint.
  # All connections from the KES client to the TLS proxy as well
  # the connections from the TLS proxy to the KES server must be
  # established over TLS.
  proxy:
    # The identities of all TLS proxies directly connected to the
    # KES server.
    #
    # Note that a TLS proxy can act as any identity (including root)
    # since it can forward arbitrary client certificates. Client certificates
    # aren't secret information and a malicious TLS proxy can fake any
    # identity it has seen before. Therefore, its critical that all TLS proxy
    # identities are secure and trusted servers.
    identities: []
    # The HTTP header sent by the TLS proxy to forward certain data
    # about the client to the KES server.
    header:
      # The HTTP header containing the URL-escaped and PEM-encoded
      # certificate of the kes client forwarded by the TLS proxy.
      cert: X-Tls-Client-Cert

# The API configuration. The APIs exposed by the KES server can
# be adjusted here. Each API is identified by its API path.
#
# In general, the KES server uses reasonable defaults for all APIs.
# Only customize the APIs if there is a real need.
# 
# Disabling authentication for an API must be carefully evaluated.
# One example, when disabling authentication may be justified, would
# be the liveness and readiness probes in a Kubernetes environment.
#
# When authentication is disabled, the particular API can be
# accessed by any client that can send HTTPS requests to the
# KES server.
#
# When disabling authentication for any API, the KES server will
# change its TLS handshake behavior. By default, KES requires that
# a client sends a client certificate during the handshake or KES
# aborts the handshake. This means that a client can only send an
# HTTP request to KES when it provides a certificate during the
# handshake. This is no longer the case when authentication is 
# disabled for at least one API. Clients should be able to call
# the API even without a certificate. Hence, KES can no longer
# require a certificate during the TLS handshake but instead has
# to check the certificate when executing the API handler. 
# 
# Now, these two behaviors have slightly different semantics:
# By default, KES does not accept connections from clients without
# a TLS certificate. When disabling authentication for one API, KES
# has to accept connections from any client for all APIs. However,
# the API handlers that still require authentication will reject
# requests from clients without a certificate. Instead of a TLS
# error these clients will receive an HTTP error.
#
# Currently, authentication can only be disabled for the
# following APIs:
#   - /v1/ready
#   - /v1/status
#   - /v1/metrics
#   - /v1/api
#
api:
  /v1/ready:
    skip_auth: false
    timeout:   15s
    
# The (pre-defined) policy definitions.
#
# A policy must have an unique name (e.g my-app) and specifies which
# server APIs can be accessed. An API path pattern is a glob pattern
# of the following form:
#   <API-version>/<API>/<operation>/[<argument-0>/<argument-1>/...]>
#
# Each KES server API has an unique path - for example, /v1/key/create/<key-name>.
# A client request is allowed if and only if no deny pattern AND at least one
# allow pattern matches the request URL path.
#
# A policy has zero (by default) or more assigned identities. However,
# an identity can never be assigned to more than one policy at the same
# time. So, one policy has N assigned identities but one identity is
# assigned to at most one policy.
#
# In general, each user/application should only have the minimal
# set of policy permissions to accomplish whatever it needs to do.
# Therefore, it is recommended to define policies based on workflows
# and then assign them to the identities.

# The following policy section shows some example policy definitions.
# Please remove/adjust to your needs.
policy:
  my-app:
    allow:
    - /v1/key/create/my-app*
    - /v1/key/generate/my-app*
    - /v1/key/decrypt/my-app*
    deny:
    - /v1/key/generate/my-app-internal*
    - /v1/key/decrypt/my-app-internal*
    identities:
    - df7281ca3fed4ef7d06297eb7cb9d590a4edc863b4425f4762bb2afaebfd3258
    - c0ecd5962eaf937422268b80a93dde4786dc9783fb2480ddea0f3e5fe471a731

  my-app-ops:
    allow:
    - /v1/key/delete/my-app*
    - /v1/policy/show/my-app
    - /v1/identity/assign/my-app/*
    identities:
    - 7ec8095a5308a535b72b35c7ccd4ce1d7c14af713acd22e2935a9d6e4fe18127

cache:
  # Cache expiry specifies when cache entries expire.
  expiry:
    # Period after which any cache entries are discarded.
    # It determines how often the KES server has to fetch
    # a secret key from the KMS.
    #
    # If not set, KES will default to an expiry of 5 minutes.
    any: 5m0s
    # Period after which all unused cache entries are discarded.
    # It determines how often "not frequently" used secret keys
    # must be fetched from the KMS.
    #
    # If not set, KES will default to an expiry of 30 seconds.
    unused: 20s
    # Period after which any cache entries in the offline cache
    # are discarded.
    # It determines how long the KES server can serve stateless
    # requests when the KMS key store has become unavailable -
    # for example, due to a network outage.
    #
    # If not set, KES will disable the offline cache.
    #
    # Offline caching should only be enabled when trying to
    # reduce the impact of the KMS key store being unavailable.
    offline: 0s

# The console logging configuration. In general, the KES server
# distinguishes between (operational) errors and audit events.
# By default, the KES server logs error events to STDERR but
# does not log audit log events to STDOUT.
#
# The following log configuration only affects logging to console.
log:
  # Enable/Disable logging error events to STDERR. Valid values
  # are "on" or "off". If not set the default is "on". If no error
  # events should be logged to STDERR it has to be set explicitly
  # to: "off".
  error: on

  # Enable/Disable logging audit events to STDOUT. Valid values
  # are "on" and "off". If not set the default is "off".
  # Logging audit events to STDOUT may flood your console since
  # there will be one audit log event per request-response pair.
  #
  # For tracing/monitoring audit logs take a look at the
  # /v1/log/audit/trace API.
  #
  # Each audit event is a JSON object representing a request-response
  # pair that contains the time, client identity, the API path, HTTP
  # response status code etc.
  # {
  #   "time": "2006-01-02T15:04:05Z07:00",
  #   "request": {
  #     "ip":       "87.149.99.199",
  #     "path":     "/v1/key/create/my-app-key",
  #     "identity": "4067503933d4a78358f908a2df7ec14e554c612acf8a9d1aa29b7da4aa018ec9",
  #   },
  #   "response": {
  #     "status": 200
  #   }
  # }
  # The server will write such an audit log entry for every HTTP
  # request-response pair - including invalid requests.
  audit: off

# In the keys section, pre-defined keys can be specified. The KES
# server will try to create the listed keys before startup.
keys:
  - name: some-key-name 
  - name: another-key-name

# The keystore section specifies which KMS - or in general key store - is
# used to store and fetch encryption keys.
# A KES server can only use one KMS / key store at the same time.
# If no store is explicitly specified the server will use store
# keys in-memory. In this case all keys are lost when the KES server
# restarts.
keystore:
  # Configuration for storing keys on the filesystem.
  # The path must be path to a directory. If it doesn't
  # exist then the KES server will create the directory.
  #
  # The main purpose of the fs configuration is testing
  # and development. It should not be used for production.
  fs:
    path: "" # Path to directory. Keys will be stored as files.
    
  # Hashicorp Vault configuration. The KES server will store/fetch
  # secret keys at/from Vault's key-value backend.
  #
  # For more information take a look at:
  # https://www.vaultproject.io/api/secret/kv/kv-v1.html
  vault:
    endpoint: ""  # The Vault endpoint - for example, https://127.0.0.1:8200
    engine: ""    # The path of the K/V engine - for example, secrets. If empty, defaults to: kv. (Vault default)
    version: ""   # The K/V engine version - either "v1" or "v2". The "v1" engine is recommended.
    namespace: "" # An optional Vault namespace. See: https://www.vaultproject.io/docs/enterprise/namespaces/index.html
    prefix: ""    # An optional K/V prefix. The server will store keys under this prefix.
    transit:      # Optionally encrypt keys stored on the K/V engine with a Vault-managed key.
      engine: ""  # The path of the transit engine - for example, "my-transit". If empty, defaults to: transit (Vault default)
      key: ""     # The key name that should be used to encrypt entries stored on the K/V engine.
    approle:    # AppRole credentials. See: https://www.vaultproject.io/docs/auth/approle.html
      namespace: "" # Optional Vault namespace used only for authentication. For the Vault root namespace, use "/".
      engine: ""    # The path to the AppRole engine, for example: authenticate. If empty, defaults to: approle. (Vault default)
      id: ""        # Your AppRole Role ID
      secret: ""    # Your AppRole Secret ID
    kubernetes: # Kubernetes credentials. See: https://www.vaultproject.io/docs/auth/kubernetes
      namespace: "" # Optional Vault namespace used only for authentication. For the Vault root namespace, use "/".
      engine: ""    # The path to the Kubernetes engine, for example: authenticate. If empty, defaults to: kubernetes. (Vault default)
      role: ""      # The Kubernetes JWT role
      jwt:  ""      # Either the JWT provided by K8S or a path to a K8S secret containing the JWT.
    tls:        # The Vault client TLS configuration for mTLS authentication and certificate verification
      key: ""     # Path to the TLS client private key for mTLS authentication to Vault
      cert: ""    # Path to the TLS client certificate for mTLS authentication to Vault
      ca: ""      # Path to one or more PEM root CA certificates
    status:     # Vault status configuration. The server will periodically reach out to Vault to check its status.
      ping: 10s   # Duration until the server checks Vault's status again.

  fortanix:
    # The Fortanix SDKMS key store. The server will store secret keys at the Fortanix SDKMS.
    # See: https://www.fortanix.com/products/data-security-manager/key-management-service
    sdkms: 
      endpoint: ""   # The Fortanix SDKMS endpoint - for example: https://sdkms.fortanix.com
      group_id: ""   # An optional group ID newly created keys will be placed at. For example: ce08d547-2a82-411e-ae2d-83655a4b7617 
                     # If empty, the applications default group is used. 
      credentials:   # The Fortanix SDKMS access credentials
        key: ""      # The application's API key - for example: NWMyMWZlNzktZDRmZS00NDFhLWFjMzMtNjZmY2U0Y2ViMThhOnJWQlh0M1lZaDcxZC1NNnh4OGV2MWNQSDVVSEt1eXEyaURqMHRrRU1pZDg=
      tls:           # The KeySecure client TLS configuration
        ca: ""       # Path to one or more PEM-encoded CA certificates for verifying the Fortanix SDKMS TLS certificate. 
  aws:
    # The AWS SecretsManager key store. The server will store
    # secret keys at the AWS SecretsManager encrypted with
    # AWS-KMS. See: https://aws.amazon.com/secrets-manager
    secretsmanager:
      endpoint: ""   # The AWS SecretsManager endpoint      - for example, secretsmanager.us-east-2.amazonaws.com
      region: ""     # The AWS region of the SecretsManager - for example, us-east-2
      kmskey: ""     # The AWS-KMS key ID used to en/decrypt secrets at the SecretsManager. By default (if not set) the default AWS-KMS key will be used.
      credentials:   # The AWS credentials for accessing secrets at the AWS SecretsManager.
        accesskey: ""  # Your AWS Access Key
        secretkey: ""  # Your AWS Secret Key
        token: ""      # Your AWS session token (usually optional)

  gemalto:
    # The Gemalto KeySecure key store. The server will store
    # keys as secrets on the KeySecure instance.
    keysecure:
      endpoint: ""    # The KeySecure endpoint - for example, https://127.0.0.1
      credentials:    # The authentication to access the KeySecure instance.
        token: ""     # The refresh token to obtain new short-lived authentication tokens.
        domain: ""    # The KeySecure domain for which the refresh token is valid. If empty, defaults to the root domain.
        retry: 15s    # The time the KES server waits before it tries to re-authenticate after connection loss.
      tls:            # The KeySecure client TLS configuration
        ca: ""        # Path to one or more PEM-encoded CA certificates for verifying the KeySecure TLS certificate.

  gcp:
    # The Google Cloud Platform secret manager.
    # For more information take a look at:
    # https://cloud.google.com/secret-manager
    secretmanager:
      # The project ID is a unique, user-assigned ID that can be used by Google APIs.
      # The project ID must be a unique string of 6 to 30 lowercase letters, digits, or hyphens.
      # It must start with a letter, and cannot have a trailing hyphen.
      # See: https://cloud.google.com/resource-manager/docs/creating-managing-projects#before_you_begin
      project_id: ""
      # An optional GCP SecretManager endpoint. If not set, defaults to: secretmanager.googleapis.com:443
      endpoint: ""
      # An optional list of GCP OAuth2 scopes. For a list of GCP scopes refer to: https://developers.google.com/identity/protocols/oauth2/scopes
      # If not set, the GCP default scopes are used.
      scopes: 
      - ""
      # The credentials for your GCP service account. If running inside GCP (app engine) the credentials
      # can be empty and will be fetched from the app engine environment automatically.
      credentials:
        client_email:   "" # The service account email                          - for example, <account>@<project-ID>.iam.gserviceaccount.com
        client_id:      "" # The service account client ID                      - for example, 113491952745362495489"
        private_key_id: "" # The service account private key                    - for example, 381514ebd3cf45a64ca8adc561f0ce28fca5ec06
        private_key:    "" # The raw encoded private key of the service account - for example, "-----BEGIN PRIVATE KEY-----\n ... \n-----END PRIVATE KEY-----\n

  azure:
    # The Azure KeyVault configuration.
    # For more information take a look at:
    # https://azure.microsoft.com/services/key-vault
    keyvault:
      endpoint: ""      # The KeyVault endpoint - for example, https://my-instance.vault.azure.net
      # Azure client credentials used to
      # authenticate to Azure KeyVault.
      credentials:
        tenant_id: ""      # The ID of the tenant the client belongs to - that is, a UUID.
        client_id: ""      # The ID of the client - that is, a UUID.
        client_secret: ""  # The value of the client secret.
      # Azure managed identity used to
      # authenticate to Azure KeyVault
      # with Azure managed credentials.
      managed_identity:
        client_id: ""      # The Azure managed identity of the client - that is, a UUID.

  entrust:
    # The Entrust KeyControl configuration.
    # For more information take a look at:
    # https://www.entrust.com/digital-security/key-management/keycontrol
    keycontrol:
      endpoint: ""     # The KeyControl endpoint - for example, https://keycontrol.my-org.com
      vault_id: ""     # The Vault ID            - for example, e30497c1-bff7-4e81-beb7-fb35c4b7410c
      box_id:   ""     # The Box name or ID      - for example, tenant-1
      # The KeyControl access credentials
      credentials:
        username: ""   # A username with access to the Vault and Box.
        password: ""   # The user password
      # The KeyControl client TLS configuration
      tls:
        ca: ""         # Path to one or more PEM-encoded CA certificates for verifying the KeyControl TLS certificate.