forked from minio/kes
-
Notifications
You must be signed in to change notification settings - Fork 0
/
server-config.yaml
372 lines (350 loc) · 17.9 KB
/
server-config.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
# 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 - e.g. "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
# 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 sane 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 - e.g. /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 -
# e.g. 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",
# "enclave": "default",
# "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.
# Configuration for storing keys on a KES server.
kes:
endpoint:
- "" # The endpoint (or list of endpoints) to the KES server(s)
enclave: "" # An optional enclave name. If empty, the default enclave will be used
tls: # The KES mTLS authentication credentials - i.e. client certificate.
cert: "" # Path to the TLS client certificate for mTLS authentication
key: "" # Path to the TLS client private key for mTLS authentication
ca: "" # Path to one or multiple PEM root CA certificates
# Configuration for storing keys via a KES KeyStore plugin or at
# a KeyStore that exposes an API compatible to the KES KeyStore
# plugin specification: https://github.com/minio/kes/blob/master/internal/generic/spec-v1.md
generic:
endpoint: "" # The plugin endpoint - e.g. https://127.0.0.1:7001
tls: # The KES client TLS configuration for mTLS authentication and certificate verification.
key: "" # Path to the TLS client private key for mTLS authentication
cert: "" # Path to the TLS client certificate for mTLS authentication
ca: "" # Path to one or multiple PEM root CA certificates
# 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 - e.g. https://127.0.0.1:8200
engine: "" # The path of the K/V engine - e.g. 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.
approle: # AppRole credentials. See: https://www.vaultproject.io/docs/auth/approle.html
engine: "" # The path of the AppRole engine - e.g. authenticate. If empty, defaults to: approle. (Vault default)
id: "" # Your AppRole Role ID
secret: "" # Your AppRole Secret ID
retry: 15s # Duration until the server tries to re-authenticate after connection loss.
kubernetes: # Kubernetes credentials. See: https://www.vaultproject.io/docs/auth/kubernetes
engine: "" # The path of the Kubernetes engine e.g. 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.
retry: 15s # Duration until the server tries to re-authenticate after connection loss.
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 multiple 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 multiple 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 - e.g.: secretsmanager.us-east-2.amazonaws.com
region: "" # The AWS region of the SecretsManager - e.g.: 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 - e.g. 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 multiple 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 - e.g. <account>@<project-ID>.iam.gserviceaccount.com
client_id: "" # The service account client ID - e.g. 113491952745362495489"
private_key_id: "" # The service account private key - e.g. 381514ebd3cf45a64ca8adc561f0ce28fca5ec06
private_key: "" # The raw encoded private key of the service account - e.g "-----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 - e.g. 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 - i.e. a UUID.
client_id: "" # The ID of the client - i.e. 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 - i.e. 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 - e.g. https://keycontrol.my-org.com
vault_id: "" # The Vault ID - e.g. e30497c1-bff7-4e81-beb7-fb35c4b7410c
box_id: "" # The Box name or ID - e.g. tenant-1
# The KeyControl access credentials
credentials:
username: "" # The username able to access the Vault and Box.
password: "" # The user password
# The KeyControl client TLS configuration
tls:
ca: "" # Path to one or multiple PEM-encoded CA certificates for verifying the KeyControl TLS certificate.