Skip to content

Working group proposal for auth#119

Merged
jdolitsky merged 6 commits intoopencontainers:mainfrom
sudo-bmitch:pr-wg-auth
Jul 7, 2023
Merged

Working group proposal for auth#119
jdolitsky merged 6 commits intoopencontainers:mainfrom
sudo-bmitch:pr-wg-auth

Conversation

@sudo-bmitch
Copy link
Copy Markdown
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
Copy Markdown

toddysm commented Nov 15, 2022

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

@sudo-bmitch
Copy link
Copy Markdown
Contributor Author

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

Yes, that should be addressed by the WG.

Comment thread proposals/wg-auth.md

## Scope

* Define registry responses to unauthenticated requests.
Copy link
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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.

Comment thread proposals/wg-auth.md Outdated
@sudo-bmitch
Copy link
Copy Markdown
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
Copy Markdown
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>
Comment thread proposals/wg-auth.md
Signed-off-by: Brandon Mitchell <git@bmitch.net>
@sagikazarmark
Copy link
Copy Markdown

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
Copy Markdown
Contributor Author

Volunteers for stakeholders and proposed owners are welcome/needed.

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

Comment thread proposals/wg-auth.md
* 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
Copy Markdown

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
Copy Markdown
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
Copy Markdown

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
Copy Markdown
Contributor Author

@toddysm proposed owners/stakeholders are needed. Feel free to nominate yourself and/or projects you represent.

Comment thread proposals/wg-auth.md

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
Copy Markdown

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
Copy Markdown

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.

Copy link
Copy Markdown
Contributor

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.

Comment thread proposals/wg-auth.md

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
Copy Markdown

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

zot

@jcarter3
Copy link
Copy Markdown

I'm happy to represent Docker Hub

@imjasonh
Copy link
Copy Markdown
Member

imjasonh commented May 4, 2023

I'm willing to represent Chainguard.

What more do we need to get this moving?

Comment thread proposals/wg-auth.md

## 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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
Member

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

@samuelkarp
Copy link
Copy Markdown
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
Copy Markdown
Contributor Author

LGTM

1 similar comment
@dmcgowan
Copy link
Copy Markdown
Member

dmcgowan commented Jul 7, 2023

LGTM

Copy link
Copy Markdown
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
Copy Markdown
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
Copy Markdown
Contributor

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.