Tags: c0t3d0s0/kes
Tags
add server metrics API
This commit adds a new server API that exposes network metrics.
The new API endpoint is: `/v1/metrics`
Now, the server gathers networks metrics, like the internal
request-response latency and the number of requests that succeeded
resp. failed, and exposes them via the `v1/metrics` endpoint.
The metrics are exposed in the Prometheus exposition format:
```
# HELP kes_http_request_error Number of request that failed due to some error. (HTTP 4xx status code)
# TYPE kes_http_request_error counter
kes_http_request_error 1
# HELP kes_http_request_failure Number of request that failed due to some internal failure. (HTTP 5xx status code)
# TYPE kes_http_request_failure counter
kes_http_request_failure 0
# HELP kes_http_request_success Number of requests that have been served successfully.
# TYPE kes_http_request_success counter
kes_http_request_success 5
# HELP kes_http_response_time Histogram of request response times spawning from 10ms to 10s.
# TYPE kes_http_response_time histogram
kes_http_response_time_bucket{le="0.01"} 6
kes_http_response_time_bucket{le="0.05"} 6
kes_http_response_time_bucket{le="0.1"} 6
kes_http_response_time_bucket{le="0.25"} 6
kes_http_response_time_bucket{le="0.5"} 6
kes_http_response_time_bucket{le="1"} 6
kes_http_response_time_bucket{le="1.5"} 6
kes_http_response_time_bucket{le="3"} 6
kes_http_response_time_bucket{le="5"} 6
kes_http_response_time_bucket{le="10"} 6
kes_http_response_time_bucket{le="+Inf"} 6
kes_http_response_time_sum 0.000371124
kes_http_response_time_count 6
```
Now, the server can be monitored by a Prometheus instance that
authenticates via mTLS (like any other client) and scrapes
the `/v1/metrics` API and authenticates.
The metrics API can be accessed e.g. via cURL:
```
curl -sSL -X GET --key <key> --cert <cert> https://127.0.0.1:7373/v1/metrics -k
```
proxy: fix invalid check to enable authentication This commit fixes a bug in the server initialization w.r.t. requiring TLS certificate verification of TLS proxies. Currently, the certificate of the TLS proxy is not validated by default / when `--auth` is not set to `off`. However, this has no direct security impact since a TLS proxy has to be explicitly configured and its public key has to be pinned. This commit fixes this by always enabling TLS certificate validation for TLS proxies unless `--auth=off` has been specified.
rename the KES client env. variables for the client key and cert This commit renames the client env. variables used to specify the client certificate and private key. Before, the CLI client expected: ``` export KES_CLIENT_TLS_CERT_FILE=<cert> export KES_CLIENT_TLS_KEY_FILE=<key> ``` Now, the CLI client expects: ``` export KES_CLIENT_CERT=<cert> export KES_CLIENT_KEY=<key> ``` The reason for this change is that the previous env. variables are quite verbose and look odd compared to the `KES_SERVER` variable. The new variables are more compact and don't require boilerplate typing. It has been considered to have a fallback - like if `KES_CLIENT_CERT` is not present look for `KES_CLIENT_TLS_CERT_FILE`. However, it seems worse to have a deprecated fallback that gets removed at some point in time. A clean cut seems better here.
add support for config file identity templates
This commit adds support for config file templates such
that an identity in the config file can be overwritten by
a config file:
```yaml
root: ${ROOT_ID}
policy:
my-policy:
paths:
- /v1/key/create/my-key
identities:
- 6d56ee07446b7f11ad3b52d3cfd90942ad636c01288d3652a29fa0647919a3b2
- ${MY_APP_ID}
```
The above config snippet would compile to an actual config where
the root identity would be replaced by the $ROOT_ID env. variable.
Similarly, there would be two identities assigned to the `my-policy`
policy:
- 6d56ee07446b7f11ad3b52d3cfd90942ad636c01288d3652a29fa0647919a3b2
- The value of $MY_APP_ID
This templating approach has some adv. compared to allowing overwriting
arbitrary config file entries:
- A user/admin providing the config file can control what can be
customized by an executing system (K8S). The user/admin still
specifies how the general setup should look like.
- Only certain aspects of the config are "dynamic" - e.g. identities.
Whether e.g. audit logging to STDOUT is enabled should not really
be configured via an env. variable.
remove the restriction of only supporting HTTP/2 This commit allows clients to connect to the KES server via any HTTP protocol (again). This commit basically reverts b74bb38. The reason for restriction to HTTP/2-only was the potential addition of stream APIs for encryption and decryption. However, nginx does not support HTTP/2 for backend connections. See: https://trac.nginx.org/nginx/ticket/923 Therefore, it would not be possible to run a KES server behind a nginx proxy since the nginx would not be able to connect to KES. Further, this commit fixes 3 typos in the reference config file.
build a versioned KES binary in docker container This commit uses the `release` command added by 08be13b to build a binary with release information when building the docker image. This can be verified by running: ``` docker build - < Dockerfile ``` and then ``` docker run <container-id> -v ```
PreviousNext