Skip to content
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

Merged
merged 6 commits into from
Jul 7, 2023

Conversation

sudo-bmitch
Copy link
Contributor

@sudo-bmitch sudo-bmitch commented Nov 11, 2022

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:

Signed-off-by: Brandon Mitchell <git@bmitch.net>
@toddysm
Copy link

toddysm commented Nov 15, 2022

@sudo-bmitch I guess this WG will address opencontainers/distribution-spec#338 - correct?

@sudo-bmitch
Copy link
Contributor Author

@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.
Copy link
Member

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?

Copy link
Contributor Author

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).

@dmcgowan
Copy link
Member

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.

proposals/wg-auth.md Outdated Show resolved Hide resolved
@sudo-bmitch
Copy link
Contributor Author

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>
@dmcgowan
Copy link
Member

@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>
@sagikazarmark
Copy link

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)

@sudo-bmitch
Copy link
Contributor Author

Volunteers for stakeholders and proposed owners are welcome/needed.

@vsoch
Copy link
Contributor

vsoch commented Jan 17, 2023

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).
Copy link

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?

Copy link
Contributor Author

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.

@toddysm
Copy link

toddysm commented Jan 30, 2023

@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.

@sudo-bmitch
Copy link
Contributor Author

@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)
Copy link

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)

Copy link

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.

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]
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can represent the following projects and tools:

oras
notation
ACR CLI

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

zot

@jcarter3
Copy link

I'm happy to represent Docker Hub

@imjasonh
Copy link
Member

imjasonh commented May 4, 2023

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.
Copy link
Member

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?

Copy link
Member

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>
@sajayantony
Copy link
Member

Looks like we have enough stake holders. Request the @opencontainers/tob to consider kicking this off.

@samuelkarp
Copy link
Member

samuelkarp commented Jul 7, 2023

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.

@sudo-bmitch
Copy link
Contributor Author

LGTM

1 similar comment
@dmcgowan
Copy link
Member

dmcgowan commented Jul 7, 2023

LGTM

Copy link
Member

@vbatts vbatts left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Contributor

@estesp estesp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jdolitsky
Copy link
Member

got 6 out of 9 votes, merging

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet