Uploaded image for project: 'Satellite'
  1. Satellite
  2. SAT-19421

Container registries for Sat and Capsule set wrong token expiration field

XMLWordPrintable

    • Sprint 122, Sprint 123, Sprint 124, Sprint 125, Sprint 126, Sprint 127, Sprint 128, Sprint 129, Sprint 130, Sprint 131
    • Moderate
    • None

      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.

          There are no Sub-Tasks for this issue.

              rhn-engineering-qjames Quinn James
              jira-bugzilla-migration RH Bugzilla Integration
              Sam Bible Sam Bible
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: