[Proposal] design document for authentication rework #3417
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
|
Oh project checks... I just hate you. |
apostasie
force-pushed
the
design-auth
branch
2 times, most recently
from
86b0ad3
to
a8f336a
Compare
apostasie
force-pushed
the
design-auth
branch
2 times, most recently
from
fd39c86
to
0d49eab
Compare
AkihiroSuda
added
documentation
AkihiroSuda
reviewed
Sep 18, 2024
| Docker will not recognize this schema, hence will not wrongly send these | ||
| credentials when trying to log in into a known _endpoint_ as a registry. | ||
|
|
||
| The schema is: `nerdctl-experimental://namespace.example:123/?endpoint=myserver.example:456` |
There was a problem hiding this comment.
Where is this expected to be stored?
There was a problem hiding this comment.
Inside the normal docker config location.
There was a problem hiding this comment.
Yes, it is possible to save and retrieve it.
The docker cli will just never use it (and we want it that way)
AkihiroSuda
reviewed
Sep 18, 2024
apostasie
force-pushed
the
design-auth
branch
from
0d49eab
to
0c134ff
Compare
Our current implementation of login suffers from structural issues manifest in a variety of ways (see containerd#3072), and is vastly incomplete when it comes to supporting hosts.toml properly. The core issue is that it predates these mechanisms, and has been architected with different requirements in mind that need to be re-evaluated today, especially in light of upcoming features like oauth device-flow. First and foremost though, it lacks a lot of clarity about what is supposed to happen when, in a context where a lot of legacy features have complex interactions are effects: - the insecure-registry flag - the "default" behaviors for localhost - the use of the docker credentials store to retrieve credentials ... to a point that even seasoned contributors are confused as to whether we should allow a scheme to be passed in front of a registry url when we do login, or what exactly should happen in term of downgrading protocols or implied port and schemes. Besides the bugs, reconciling these legacy features, the requirement to use docker credentials, and being able to actually use hosts.toml does require significant changes to our login and dockerconfigresolver code. Some of these details are outlined in containerd#3265 - though this is not the place for a proper reference. This document offers solutions, and describes precisely what happens when and how things work together. It is not a replacement for the hosts.toml slapstick spec, but rather a description of what we want to achieve with the upcoming rewrite. While there is a lot of important details in there that should not be overlooked, the key parts of the proposal are the introduction of a new flag allowing to log in into endpoints, an experimental scheme for storing endpoint credentials, and clarification on the role and use of --insecure-registry flag. Signed-off-by: apostasie <[email protected]>
apostasie
force-pushed
the
design-auth
branch
from
0c134ff
to
b5d1e08
Compare
|
@fahedouch would love your opinion here overall. The take-away really is:
|
|
@AkihiroSuda once I get the testing/CI work done, is it fine with you that I move to implementation of this? It might be simpler for people to discuss with actual code? |
Merged
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.
Our current implementation of login suffers from structural issues manifest in a variety of ways (see #3072), and is vastly incomplete when it comes to supporting hosts.toml properly.
The core issue is that it predates these mechanisms, and has been architected with different requirements in mind that need to be re-evaluated today, especially in light of upcoming features like oauth device-flow.
First and foremost though, it lacks a lot of clarity about what is supposed to happen when, in a context where a lot of legacy features have complex interactions and effects:
... to a point that even seasoned contributors are confused as to whether we should allow a scheme to be passed in front of a registry url when we do login, or what exactly should happen in term of downgrading protocols or implied port and scheme.
Besides the bugs, reconciling these legacy features, the requirement to use docker credentials, and being able to actually use hosts.toml does require significant changes to our login and dockerconfigresolver code - aka: a full rewrite.
Some of these details are outlined in #3265 - though this is not the place for a proper reference - and some of the groundwork for this rewrite have been recently merged.
This document offers solutions, and describes precisely what happens when, and how things interact together. It is not a replacement for the hosts.toml slapstick spec, but rather a description of what we want to achieve with the upcoming rewrite.
While there is a lot of important details in there that should not be overlooked, the key parts of the proposal are the introduction of a new nerdctl login flag allowing to authenticate with endpoints, an experimental scheme for storing endpoint credentials, and clarification on the role and use of the --insecure-registry flag.
Given the extent of the changes to come - that will be very hard to break down into small pieces - I felt like it was better to start here and making sure we are aligned on the vision.
Cheers.