add support for API keys #328
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
aead
added
the
release-notes
aead
force-pushed
the
api-key
branch
2 times, most recently
from
13cf5fd to
d9c7633
Compare
aead
force-pushed
the
api-key
branch
3 times, most recently
from
63c175a to
61b3a43
Compare
klauspost
reviewed
Feb 10, 2023
This commit adds API keys as secret-based authentication mechanism. An API key has the following format: ``` kes:v1:base64-encode(<key-type> | <key-bytes>) key-type: 1 byte key algorithm identifier key-bytes: value of the secret key ``` An example API key looks like this: ``` kes:v1:ACQpoGqx3rHHjT938Hfu5hVVQJHZWSqVI2Xp1KlYxFVw ``` Like TLS certificates, an API has a corresponding identity. The identity of the example API key above is: ``` 0426fa9a04bc2756b92fbe8a97e1a1e07b53ecf04ed33da22c33e5c9faeb8cbb ``` Now, the `kes identity new` and `kes identity of`, by default, generate an API key resp. compute the identity from an API key. *** Under the hood, an API key deterministically generates a private/public key pair - from which a CA-signed / self-signed certificate can be generated. However, with API keys it is possible to generate a TLS certificate, e.g. for mTLS authentication, on the fly from a single secret value. Hence, API keys still boil down to private/public key / TLS-based authentication. However, the simply key management when certificates don't need to be signed by a publicly trusted CA but instead are used for internal machine-to-machine communication. In particular, a client requires just the API key while the server just requires the corresponding identity. Furthermore, the server does not hold any secret (identities aren't secret information). So, we don't have to worry about compromise of API keys from the server-side. Signed-off-by: Andreas Auernhammer <[email protected]> Co-authored-by: Klaus Post <[email protected]> Signed-off-by: Andreas Auernhammer <[email protected]>
aead
added a commit
to minio/minio
that referenced
this pull request
Feb 14, 2023
This commit adds support for KES API keys. A detailed explanation of API keys can be found here: minio/kes#328 This commit introduces a new env. var. ``` MINIO_KMS_KES_API_KEY ``` Either an explicit client certificate or an API key can be set. Further, this commit replaces the `github.com/minio/kes` dependency with `github.com/minio/kes-go` containing the new offical KES SDK for Go. Signed-off-by: Andreas Auernhammer <[email protected]>
8 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit adds API keys as secret-based
authentication mechanism.
An API key has the following format:
An example API key looks like this:
Like TLS certificates, an API has a corresponding
identity. The identity of the example API key
above is:
Now, the
kes identity newandkes identity of, by default, generate an API key resp. compute the identity from an API key.Under the hood, an API key deterministically generates a private/public key pair - from which a CA-signed / self-signed certificate can be generated.
However, with API keys it is possible to generate
a TLS certificate, e.g. for mTLS authentication, on the fly from a single secret value.
Hence, API keys still boil down to private/public
key / TLS-based authentication. However, the simply key management when certificates don't need to be
signed by a publicly trusted CA but instead are used for internal machine-to-machine communication.
In particular, a client requires just the API key
while the server just requires the corresponding identity. Furthermore, the server does not hold any secret
(identities aren't secret information). So, we don't have to worry about compromise of API keys from the server-side.