Bug 2229810

Summary: Container registries for Sat and Capsule set wrong token expiration field
Product: Red Hat Satellite Reporter: Ian Ballou <iballou>
Component: Container Management - ContentAssignee: satellite6-bugs <satellite6-bugs>
Status: NEW --- QA Contact: Satellite QE Team <sat-qe-bz-list>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.12.2CC: vcojot
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ian Ballou 2023-08-07 19:07:52 UTC
Description of problem:

Relates to an RHOSP BZ: https://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 but 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.