-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Working group proposal for auth #119
Conversation
Signed-off-by: Brandon Mitchell <git@bmitch.net>
@sudo-bmitch I guess this WG will address opencontainers/distribution-spec#338 - correct? |
Yes, that should be addressed by the WG. |
|
||
## Scope | ||
|
||
* Define registry responses to unauthenticated requests. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this referring to the "anonymous" pull case where an authentication server is giving out tokens for unauthenticated requests?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking of requests where either there is no Authorization header, or the token in the header does not apply to the request (a pull token used to push, or a token for a different repository being reused for a future request).
I agree with having the working group for drafting the spec. It was unclear from the scope where there is any "new" functionality or use cases which this group is also aiming to support/investigate. I would consider "new" to be cases not currently support by a majority of clients/registries. |
There are probably some edge cases, but a majority of the effort will be standardizing something that should work with existing servers and clients. Do we need new functionality to be a working group? |
Signed-off-by: Brandon Mitchell <git@bmitch.net>
Signed-off-by: Brandon Mitchell <git@bmitch.net>
@sudo-bmitch no, just to avoid scope creep and a never ending working group. Most the efforts to standardize existing behavior allowed limited new functionality, except for known limitations/pain points. |
Signed-off-by: Brandon Mitchell <git@bmitch.net>
Signed-off-by: Brandon Mitchell <git@bmitch.net>
I'm glad to see this is happening. I have a working implementation of the Docker registry authorization server spec here: https://github.com/distribution-auth/auth I've spent some time with registry authnz lately, so I'd be happy to help however I can (work on spec, tinker with implementation, etc) |
Volunteers for stakeholders and proposed owners are welcome/needed. |
There has been some discussion in the ORAS community about use of the Docker credential file in this flow (about how many tools do it but it’s not a standard) so I’d like to suggest this is considered to be in scope here. It would be ideal to have the full flow from defining the credential through authorization standardized for common tooling and less adhoc standards in the space as we have now. |
* Specify how clients negotiate access to multiple repositories for actions like a cross-repository blob mount. | ||
* Specify how clients and registries should renegotiate access for a request with expired or insufficient authorization. | ||
* Specify expected lifetime of registry credentials. | ||
* Avoid specifications that would prevent future extensibility (e.g. fine grain access control). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does that mean no discussions about ABAC?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say we discuss it enough to know that we aren't excluding the possibility from future specs.
@sudo-bmitch what are the next steps for this WG? I will be interested to participate because we are regularly hitting issues with auth with various registries. |
@toddysm proposed owners/stakeholders are needed. Feel free to nominate yourself and/or projects you represent. |
|
||
The following have agreed to participate in the working group, review progress, report progress back to the OCI community, and present the results to the TOB once the working group has completed its objectives. | ||
|
||
* Brandon Mitchell (@sudo-bmitch) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would you mind adding me:
Toddy Mladenov (@toddysm)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rchincha Would you like to be part of the WG? I saw that you added zot below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, pls add me if no concerns/objections.
|
||
OCI Projects, non-OCI projects, or organizations sponsoring the working group and participating in the implementation and use case validation of the work done by the group. | ||
|
||
* [regclient][regclient] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm happy to represent Docker Hub |
I'm willing to represent Chainguard. What more do we need to get this moving? |
|
||
## Stakeholders | ||
|
||
OCI Projects, non-OCI projects, or organizations sponsoring the working group and participating in the implementation and use case validation of the work done by the group. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the target of this WG is the distribution-spec, are there any other maintainers of the spec who can act as stakeholders?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wave.. I can rep for distribution
Signed-off-by: Brandon Mitchell <git@bmitch.net>
Looks like we have enough stake holders. Request the @opencontainers/tob to consider kicking this off. |
I'll call the vote for @opencontainers/tob. Please approve, request changes, reply with LGTM, or not (and hopefully say why!). A 2/3 approval is required here, so 6/9 of the TOB members must approve. |
LGTM |
1 similar comment
LGTM |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
got 6 out of 9 votes, merging |
Signed-off-by: Brandon Mitchell git@bmitch.net
This PR proposes a new working group to specify authentication and authorization between registries and clients.
References: