Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2229810 - Container registries for Sat and Capsule set wrong token expiration field
Summary: Container registries for Sat and Capsule set wrong token expiration field
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Container Management - Content
Version: 6.12.2
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: 6.15.0
Assignee: Quinn James
QA Contact: Sam Bible
URL:
Whiteboard:
: 2138743 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-08-07 19:07 UTC by Ian Ballou
Modified: 2024-04-23 17:12 UTC (History)
4 users (show)

Fixed In Version: rubygem-smart_proxy_container_gateway-1.1.0-1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2024-04-23 17:12:06 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 36827 0 Normal Ready For Testing Container registries for Sat and Capsule set wrong token expiration field 2023-11-06 19:48:25 UTC
Red Hat Issue Tracker SAT-19421 0 None None None 2023-08-07 19:13:09 UTC
Red Hat Product Errata RHSA-2024:2010 0 None None None 2024-04-23 17:12:07 UTC

Description Ian Ballou 2023-08-07 19:07:52 UTC
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.

Comment 2 Quinn James 2023-10-12 20:38:22 UTC
Created redmine issue https://projects.theforeman.org/issues/36827 from this bug

Comment 3 Brad Buckingham 2023-10-30 11:29:29 UTC
Bulk setting Target Milestone = 6.15.0 where sat-6.15.0+ is set.

Comment 5 Ian Ballou 2023-10-31 18:23:25 UTC
*** Bug 2138743 has been marked as a duplicate of this bug. ***

Comment 9 Sam Bible 2024-02-07 03:35:03 UTC
Tested on 6.15 Snap 8

Steps to Verify:
1. Create and sync a container repo
2. Add this to a CV, publish it and promote it to an LCE
3. run podman pull <image> with the LCE set to allow unauthorized pull, with the --log-level set to trace
4. View the token that is returned as part of the verbose logging
5. Change the LCE to not allow unauthorized pulls, and run podman login
6. Then run podman pull <image> --log-level trace again
7. View the token that is returned in the logs.
8. Create and Sync a capsule, and add the LCE to the capsule
9. Try both unauthorized and authorized pulls of the repo from the capsule as well.

Expected Results: 
Both tokens follow this format: {"token":"unauthenticated","expires_in":180,"issued_at":"2024-02-06T20:48:29-05:00","expires_at":"2024-02-06T19:51:29-06:00"} - specifically, the time format for the expires_at field, and the presence of the expires_in field
On the capsule, it looks like this {"token":"unauthorized","issued_at":"2024-02-06T22:31:01-05:00","expires_in":31556952} - note the presence of the expired_in here

Actual Results:
Both tokens follow this format: {"token":"unauthenticated","expires_in":180,"issued_at":"2024-02-06T20:48:29-05:00","expires_at":"2024-02-06T19:51:29-06:00"} - specifically, the time format for the expires_at field, and the presence of the expires_in field
On the capsule, it looks like this {"token":"unauthorized","issued_at":"2024-02-06T22:31:01-05:00","expires_in":31556952} - note the presence of the expired_in here

Comment 12 errata-xmlrpc 2024-04-23 17:12:06 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Important: Satellite 6.15.0 release), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2024:2010


Note You need to log in before you can comment on or make changes to this bug.