OCI publishing to Azure fails (token vs access_token)

Bug #1970187 reported by Tomáš Virtus
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
Triaged
High
Unassigned

Bug Description

I've configured a push rule for ACR (Azure Container Registry) on
Ubuntu 18.04 OCI recipe at

  https://launchpad.net/~cloud-images-release-managers/cloud-images/+oci/ubuntu-base/+recipe/18.04

with following fields:

  Registry URL: ubuntu.azurecr.io
  Image name: ubuntu
  Username: ubuntu
  Password: <REDACTED>

When I triggered new build, the push failed when logging in into ACR
registry with the following message:

  Registry upload failed: Could not get token from response data:
  {'access_token': '... JWT TOKEN SNIPPED ...'}

The failed build URL is

  https://launchpad.net/~cloud-images-release-managers/cloud-images/+oci/ubuntu-base/+recipe/18.04/+build/4425

I've done some digging with (patched) skopeo and Wireshark. In
ociregistryclient.py BearerTokenRegistryClient.authenticate() fetches
"token" from the /oauth2/token response. When logging in into
Docker.io registry, the response JSON contains keys "token",
"access_token", "expires_in" and "issued_at", and "token" has the same
value as "access_token". But ACR registry response contains only
"access_token". I'm OAuth ignorant person but it seems that
"access_token" should be used instead of "token". At least that's what
skopeo seems to do, it doesn't have any problem with ACR response.

I'm attaching captured HTTP exchange between skopeo and remote
registry for the following commands as text files in attached tarball
(with my credentials redacted):

  skopeo login docker.io
  skopeo inspect --raw docker://ubuntu/ubuntu:focal

  skopeo login vubuntu.azurecr.io
  skopeo inspect --raw docker://vubuntu.azurecr.io/ubuntu:focal-20.04_edge

Both images are private so authentication/authorization is required.

Tags: oci
Revision history for this message
Tomáš Virtus (virtustom) wrote :
Revision history for this message
Jürgen Gmach (jugmac00) wrote :
Changed in launchpad:
importance: Undecided → High
status: New → Triaged
Revision history for this message
Tomáš Virtus (virtustom) wrote :

Also quoting from https://docs.docker.com/registry/spec/auth/token/

  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.

All other fields are optional whereas at least one of token or
access_token has to be present and they have to be same if both are.
So I think an easy fix would be as demonstrated in attached patch,
though it doesn't touch unit tests at all.

Revision history for this message
Tomáš Virtus (virtustom) wrote :

FYI, I'm just working on moving image pushes from LP to CPC Jenkins, so priority for this can be lowered, as we (CPC & ROCKs) won't be using LP for publishing in near future.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.