Use subnet api key instead of license #3876
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
7 tasks
anjalshireesh
force-pushed
the
api-keys
branch
3 times, most recently
from
d0b540e
to
6aabdfc
Compare
|
Depends on minio/minio#13793 |
harshavardhana
requested changes
Dec 7, 2021
anjalshireesh
force-pushed
the
api-keys
branch
from
cef441e
to
c80d21c
Compare
kanagarajkm
approved these changes
Dec 7, 2021
harshavardhana
approved these changes
Dec 7, 2021
klauspost
reviewed
Dec 7, 2021
The earlier approach of using a license token for communicating with SUBNET is being replaced with a simpler mechanism of api keys. Unlike the license which is a JWT token, these api keys will be simple UUID tokens, and don't have any embedded information in them. SUBNET would generate the api key on cluster registration, and return in the api response. mc then stores it in the `subnet api_key` config of minio, to be used for subsequent communication with SUBNET. In case the api_key is not available in config, but the cluster's license is available, it will be used as auth in the subnet api call, and api_key will be set after the call succeeds. This will help in smooth migration from older versions of minio.
anjalshireesh
force-pushed
the
api-keys
branch
from
dabb094
to
efa988a
Compare
harshavardhana
approved these changes
Dec 9, 2021
adfost
pushed a commit
to adfost/mc
that referenced
this pull request
Oct 28, 2022
The earlier approach of using a license token for communicating with SUBNET is being replaced with a simpler mechanism of API keys. Unlike the license which is a JWT token, these API keys will be simple UUID tokens, and don't have any embedded information in them. SUBNET would generate the API key on cluster registration, and return in the API response. mc then stores it in the `subnet api_key` config of minio, to be used for subsequent communication with SUBNET. In case the api_key is not available in the config, but the cluster's license is available, it will be used as auth in the subnet API call, and api_key will be set after the call succeeds. This will help in smooth migration from older versions of MinIO.
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.
The earlier approach of using a license token for communicating with
SUBNET is being replaced with a simpler mechanism of api keys. Unlike
the license which is a JWT token, these api keys will be simple UUID
tokens, and don't have any embedded information in them. SUBNET would
generate the api key on cluster registration, and return in the api
response. mc then stores it in the
subnet api_keyconfig of minio,to be used for subsequent communication with SUBNET.
In case the api_key is not available in config, but the cluster's
license is available, it will be used as auth in the subnet api call,
and api_key will be set after the call succeeds. This will help in
smooth migration from older versions of minio.