cmd: align `kes key` command output (minio#218)

This commit aligns the output of the
`kes key {encrypt,decrypt,dek}` commands.

Further, it fixes a bug in the `kes key dek`
command. Before, `dek` wrote hex-encoded
a plaintext/ciphertext pair to STDOUT (when
redirected) -  instead of base64.
Now, the output is again encoded as base64.

Signed-off-by: Andreas Auernhammer <[email protected]>

support go.mod go1.16

kestest: add new API tests

This commit adds a set of API tests that
check that the server API behaves as expected.

Signed-off-by: Andreas Auernhammer <[email protected]>

yml: fix regression parsing policy definitions

This commit fixes a regression introduced by
a229d68.

Identities assigned to a policy in the YAML
config file have been ignored in the following
case:
```
policy:
   - my-policy:
       allow:
         - /v1/key/create/*
       identity:
         - ${MY_CLIENT_IDENTITY}
```

Before, the config file parsing expected
`identities` - not `identity`. After a229d68
`identities` has been ignored. This commit
fixes this by reverting to the previous behavior
of only honoring `identities`.

Signed-off-by: Andreas Auernhammer <[email protected]>

vault: include K/V prefix when cloning config

This commit fixes a bug introduced by a229d68
that ignores the K/V prefix when cloning the
Vault config.

This commit fixes this bug and adds a test to
ensure that a config is cloned as expected.

Signed-off-by: Andreas Auernhammer <[email protected]>

update dependencies

This commit updates some dependencies to newer/their
latest version.

Signed-off-by: Andreas Auernhammer <[email protected]>

cache: add offline caching of keys

This commit adds offline caching of keys.

KES keeps keys - fetched from the KMS key
store - in a in-memory cache to increase
performance and reduce the request rate
to the central KMS.
Entries in the cache expiry after a configurable
time period and get removed by a cache GC.

Usually it is recommended to keep the cache
expiry periods quite low - e.g.:
 - Any:    5m0s
 - Unused:  20s

In particular, low cache expiry values reduce
the time window KES can operate without interacting
with the central KMS when serving stateless
requests; e.g. generating a new data encryption key.
Note that KES can never server stateful requests,
like creating or deleting a key, without the KMS.

Especially in distributed setups, two KES servers
will sync eventually once their cache entires have
expired. For example, one KES server receives a
request to delete a key from the KMS key store.
The second KES server will not notice that this key
got deleted until its corresponding cache entry
has expired.
Low cache expiry values reduce the time window
when multiple KES servers are not synchronized.

However, low cache expiry values require that the
KMS is highly available. As soon as a cache entry
expires, KES needs to reach out to the KMS to
fetch the key again.
If the KMS is not available, KES will not be able
continue serving stateless requests.

It may be desirable to keep keys longer in the cache
to reduce the impact of the central KMS being down
and continue serving stateless requests - but only
when the KMS is actually down. When the KMS is
available, KES should expiry keys relatively quickly
and only cache them longer when the KMS is not reachable.

This commit adds this ability by another cache expiry
configuration:
```yaml
cache:
  expiry:
    any:       5m0s
    unused:     30s
    offline: 1h0m0s
```

Now, KES will cache keys for one hour if and only
if the KMS is not available. As soon as the KMS
is reachable again, KES clears the cache to sync
with the central KMS again.

If no `offline` expiry is set, KES will not cache
keys when the KMS is down. It will simply not
use an offline cache.

Signed-off-by: Andreas Auernhammer <[email protected]>

Co-authored-by: Klaus Post <[email protected]>
Signed-off-by: Andreas Auernhammer <[email protected]>

tls: add support for encrypted private keys. (minio#161)

This commit adds support for encrypted TLS private
keys.

Now, a TLS private key password can be specified
in the KES config file:
```
tls:
  key: private.key
  cert: public.crt
  password: my-password
```

If the password should not be persisted as part of
the KES configuration it can be fetched from the
environment using env. variable substitution:
```
tls:
  key: private.key
  cert: public.crt
  password: ${KES_TLS_PRIVATE_KEY_PASSWORD}
```

```
export KES_TLS_PRIVATE_KEY_PASSWORD=my-password
```

Signed-off-by: Andreas Auernhammer <[email protected]>

vault: adjust key creation/deletion to Vault API (minio#159)

This commit fixes an issue in the Vault backend.
Hashicorp Vault returns 204 (No Content) when
creating / deleting a key successfully.
Hence, the Vault SDK returns no error BUT also
no secret/entry object - since no content.

However, the Vault SDK may also return no error
AND no secret/entry object in case of some network
errors - e.g. broken network connection.

This commit works around this ambiguous behavior
by implementing the key creation / deletion using
low-level SDK primitives and explicitly checking
the HTTP response status code.

Signed-off-by: Andreas Auernhammer <[email protected]>

fix error message (minio#158)