Potential issue with path-specific authentication keys in Docker config.json

[TommsNL]

What happened in your environment?

When using a config.json file with path-specific keys in the auths section (e.g., subdomain.harbor.com/team-a), ORAS does not appear to use these specific keys for authentication. Instead, it defaults to using the general host key (e.g., subdomain.harbor.com), even if a more specific key exists.

This issue creates challenges when managing registries with different authentication scopes for specific paths.

Example:

Given the following config.json:

{
    "auths": {
        "subdomain.harbor.com/team-a": {
            "auth": "BASE64_ENCODED_CREDS_TEAM_A"
        },
        "subdomain.harbor.com": {
            "auth": "BASE64_ENCODED_GENERAL_CREDS"
        }
    }
}

When running:

oras push --artifact-type application/x-gzip subdomain.harbor.com/team-a/artifact:1.0.0 artifact.tar.gz

ORAS appears to use the credentials for subdomain.harbor.com instead of subdomain.harbor.com/team-a.

I tested this behavior by setting up multiple credentials in the auths section with path-specific keys.

What did you expect to happen?

I expected ORAS to:

1. Look for an exact match of the registry key, including paths (e.g., subdomain.harbor.com/team-a).
2. Use the path-specific credentials if a match is found.
3. Fallback to the general host key (subdomain.harbor.com) only if no exact match exists.

This behavior aligns with Docker's implementation for config.json files and is essential for managing credentials with path-specific scopes.

How can we reproduce it?

Scenario 1: Path-specific key only

1. Create a config.json file with the following structure:

{
    "auths": {
        "subdomain.harbor.com/team-a": {
            "auth": "BASE64_ENCODED_CREDS_TEAM_A"
        }
    }
}

2. Attempt to perform an oras push to subdomain.harbor.com/team-a
3. Expected behavior: ORAS should use the path-specific credentials for subdomain.harbor.com/team-a and successfully push the artifact.
4. Observed behavior: ORAS returns a 401 Unauthorized error, indicating that it failed to pick up the path-specific credentials.

Scenario 2: General host key only

1. Create a config.json file with only the general host key:

{
    "auths": {
        "subdomain.harbor.com": {
            "auth": "BASE64_ENCODED_CREDS_TEAM_A"
        }
    }
}

2. Attempt to perform an oras push to subdomain.harbor.com/team-a
3. Expected behavior: ORAS should fallback to the general host key and successfully push the artifact.
4. Observed behavior: ORAS successfully pushes the artifact, confirming that it uses the general host key.

By testing both scenarios, we can verify whether ORAS properly distinguishes between general and path-specific keys in the auths section of config.json. This distinction is critical for managing credentials in environments with path-specific scopes.

What registry are we using?

Harbor (https://goharbor.io/)

What is the version of your ORAS CLI?

Oras Version: 1.2.0

What is your OS environment?

Red Hat Universal Base Image 8 (So based on RHEL 8)

Are you willing to submit PRs to fix it?

• Yes, I am willing to fix it.

[Wwwsylvia]

Hi @TommsNL , this is a known limitation and the repository-level auth is currently not supported. We are tracking the feature request on the backing library repo: oras-project/oras-go#840

[TommsNL]

Hi @TommsNL , this is a known limitation and the repository-level auth is currently not supported. We are tracking the feature request on the backing library repo: oras-project/oras-go#840

Thanks for the reply @Wwwsylvia i'll be tracking oras-project/oras-go#840 then

[TerryHowe]

I thought Harbor called them namespaces

[FeynmanZhou]

Support retrieve and authenticate with path-specific authentication keys in config.json sounds like a valid feature request to me.

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[TerryHowe]

This might be covered by the registries.conf feature that was talked about. I still haven't read the spec though.