Project

Profile

Help

Story #4938

Updated by lmjachky 3 months ago

We need to add auth mechanism to Pulp registry - -basic or- basic or token based.

This ticket will be complete when a token based auth mechanism will be added.

-Basic Basic auth mechanism will be solved in a separate ticket.- ticket.

----------------------------------------------------------------------------------

1. Create a separate endpoint for accessing a token server. It might be something similar to "https://auth.docker.io/token" (localhost/token:PORT). A new app route will be required to add to the file content.py (https://github.com/pulp/pulp_docker/blob/82380e7c8cd8af2ead0f996d2950b9ab511221ad/pulp_docker/app/content.py#L3).

"https://auth.docker.io/token". An HTTP GET request for the token server will be created when a registry requires authorization. In our case, this is going

2. The server has
to happen maintain a record of authorized users within different scopes. At first, a client needs to log in every single time. Users are not managed by (send an HTTP GET request) with credentials provided in a centralized access control yet, therefore, requests will contain no information about users ("sub": "anonymous"). An authentication request header. "As of users is not handled by this issue. See Docker 1.8, the issue https://pulp.plan.io/issues/5338 registry client in the Docker Engine only supports Basic Authentication to learn more. these token servers."

2. For example, a user/docker daemon can execute the following command in order to accomplish the authentication:

<pre><code class="text">
curl -Lv -u <username>:<password> "https://sso.redhat.com/auth/realms/rhcc/protocol/redhat-docker-v2/auth?service=docker-registry&client_id=curl&scope=repository:rhel:pull"
</code></pre>

3.
If the user is attempting to access a permitted scope, the token server generates an implementation specific token and returns it in a response.

<pre><code class="text">
HTTP/1.1 200 OK
Content-Type: application/json

{"token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsImtpZCI6IlBZWU86VEVXVTpWN0pIOjI2SlY6QVFUWjpMSkMzOlNYVko6WEdIQTozNEYyOjJMQVE6WlJNSzpaN1E2In0.eyJpc3MiOiJhdXRoLmRvY2tlci5jb20iLCJzdWIiOiJqbGhhd24iLCJhdWQiOiJyZWdpc3RyeS5kb2NrZXIuY29tIiwiZXhwIjoxNDE1Mzg3MzE1LCJuYmYiOjE0MTUzODcwMTUsImlhdCI6MTQxNTM4NzAxNSwianRpIjoidFlKQ08xYzZjbnl5N2tBbjBjN3JLUGdiVjFIMWJGd3MiLCJhY2Nlc3MiOlt7InR5cGUiOiJyZXBvc2l0b3J5IiwibmFtZSI6InNhbWFsYmEvbXktYXBwIiwiYWN0aW9ucyI6WyJwdXNoIl19XX0.QhflHPfbd6eVF4lM9bwYpFZIV0PfikbyXuLx959ykRTBpe3CYnzs6YBK8FToVb5R47920PVLrh8zuLzdCr9t3w", "expires_in": 3600,"issued_at": "2009-11-10T23:00:00Z"}
</code></pre>

To generate a secure token, the library PyJWT (https://pypi.org/project/PyJWT/) can be used. The generated token will be then used by a client in subsequent requests. The registry will proceed further with authenticated pull/push calls along with the bearer token.

<pre><code class="text">
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsImtpZCI6IkJWM0Q6MkFWWjpVQjVaOktJQVA6SU5QTDo1RU42Ok40SjQ6Nk1XTzpEUktFOkJWUUs6M0ZKTDpQT1RMIn0.eyJpc3MiOiJhdXRoLmRvY2tlci5jb20iLCJzdWIiOiJCQ0NZOk9VNlo6UUVKNTpXTjJDOjJBVkM6WTdZRDpBM0xZOjQ1VVc6NE9HRDpLQUxMOkNOSjU6NUlVTCIsImF1ZCI6InJlZ2lzdHJ5LmRvY2tlci5jb20iLCJleHAiOjE0MTUzODczMTUsIm5iZiI6MTQxNTM4NzAxNSwiaWF0IjoxNDE1Mzg3MDE1LCJqdGkiOiJ0WUpDTzFjNmNueXk3a0FuMGM3cktQZ2JWMUgxYkZ3cyIsInNjb3BlIjoiamxoYXduOnJlcG9zaXRvcnk6c2FtYWxiYS9teS1hcHA6cHVzaCxwdWxsIGpsaGF3bjpuYW1lc3BhY2U6c2FtYWxiYTpwdWxsIn0.Y3zZSwaZPqy4y9oRBVRImZyv3m_S9XDHF1tWwN7mL52C_IiA73SJkWVNsvNqpJIn5h7A2F8biv_S2ppQ1lgkbw
</code></pre>

* We can implement exactly the same behavior as it is described in the authentication scheme https://docs.docker.com/registry/spec/auth/token/. Pulp I am not sure if a docker daemon can send authorization requests automatically or it is managed by a client himself. We still only needs need to check user's permissions and generate a bearer token according to submitted scope and actions.

It is possible to utilize the deleted implementation of JWT https://github.com/pulp/pulpcore/commit/9df430aa7511d5a66927b2b67d02997f18a694b6. It was deleted because there was a no viable use case for the
that.

References:
https://docs.docker.com/registry/spec/auth/jwt/
https://docs.docker.com/registry/spec/auth/oauth/
https://docs.docker.com/registry/spec/auth/token/
https://access.redhat.com/articles/3560571

Back