Project

General

Profile

Actions

Bug #36827

closed

Katello container registries set wrong token expiration field

Added by Quinn James about 1 year ago. Updated 12 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Container
Target version:

Description

Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=2229810

Description of problem:

Relates to an RHOSP BZ: Red Hathttps://bugzilla.redhat.com/show_bug.cgi?id=2229383#c12

The link there is to my comment with a description of the situation in Satellite.

We should be setting the "expires_in" field, but instead, we're setting the "expires_at" field. This is likely an old typo that was never caught.

On top of this, we should be setting the time until expiry, like "3600", instead of that actual time that the expiration will happen.

This has the spec: https://docs.docker.com/registry/spec/auth/token/#requesting-a-token

This is also true on the Capsule, so we'll need a fix as well in the smart_proxy_container_gateway.

To add to this, we use different timing conventions for unauthenticated pull and authenticated pull. We should ensure that they match.

The mismatch caused a bug in RHOSP and the "expires_at" problem caused them to have to write a workaround for our typo: https://bugzilla.redhat.com/show_bug.cgi?id=2134075

We should also check if the issued_at date is "RFC3339-serialized UTC standard time".

Version-Release number of selected component (if applicable):

All Satellite versions with container pull.

How reproducible:

100%

Steps to Reproduce:

Look at the data sent in the token response for both authenticated and unauthenticated container repositories.

Look at the "expires_at" field and the difference in time format.

If you're using 'unauthenticated pull', your token time will look like:

"{\"expires_at\":\"2023-08-07T15:51:30.823+00:00\"}"

If you're using authenticated pull, your token time will look like:

"{\"expires_at\":\"2023-08-07T15:57:36.953Z\"}"

Actual results:
Mismatching times and use of "expires_at"

Expected results:
"{\"expires_in\":3600}"

Additional info:

From the docker spec:

Token Response Fields

token
An opaque Bearer token that clients should supply to subsequent requests in the Authorization header.
access_token
For compatibility with OAuth 2.0, we will also accept token under the name access_token. At least one of these fields must be specified, but both may also appear (for compatibility with older clients). When both are specified, they should be equivalent; if they differ the client's choice is undefined.

expires_in
(Optional) The duration in seconds since the token was issued that it will remain valid. When omitted, this defaults to 60 seconds. For compatibility with older clients, a token should never be returned with less than 60 seconds to live.

issued_at
(Optional) The RFC3339-serialized UTC standard time at which a given token was issued. If issued_at is omitted, the expiration is from when the token exchange completed.

refresh_token
(Optional) Token which can be used to get additional access tokens for the same subject with different scopes. This token should be kept secure by the client and only sent to the authorization server which issues bearer tokens. This field will only be set when `offline_token=true` is provided in the request.

Actions

Also available in: Atom PDF