Unable to authenticate to custom Anaconda Cloud domains for conda channel access

[danyeaw]

I'm trying to use anaconda-auth to authenticate conda to a custom Anaconda Cloud domain (stage.anaconda.com) to access private channels, but I'm encountering 403 authentication errors despite following the configuration steps.

Expected Behavior

I should be able to:

1. Configure anaconda-auth to use a custom domain (e.g., stage.anaconda.com)
2. Login using anaconda auth login
3. Use conda to install packages from authenticated channels on that domain without needing to manually pass tokens via environment variables

Current Behavior

Even after configuration and authentication, conda cannot access the authenticated channel and returns 403 errors.

Steps to Reproduce

1. Configure ~/.anaconda/config.toml:

default_site = "cloud-staging"

[sites."cloud-staging"]
domain = "stage.anaconda.com"

2. Configure ~/.condarc:

channels:
  - https://repo-latest.dev-us-east-1.anaconda.cloud/repo/wheels-test

3. Run anaconda auth login (successfully authenticates)

4. Attempt to create an environment with a package from the authenticated channel:

ANACONDA_AUTH_DOMAIN=stage.anaconda.com CONDA_TOKEN=$(anaconda auth api-key) conda create -c https://repo-latest.dev-us-east-1.anaconda.cloud/repo/wheels-test/ fastapi -p /tmp/wheels

Result: 403 authentication errors

Issues

• The authentication setup is overly complex and requires manually passing both ANACONDA_AUTH_DOMAIN and CONDA_TOKEN environment variables
• Even with these environment variables set, authentication still fails
• The anaconda auth login command doesn't appear to configure conda to automatically use the credentials for the configured domain
• There's no clear integration between anaconda-auth configuration and conda's channel authentication

Expected Workflow

The ideal workflow should be:

1. Configure the auth domain in ~/.anaconda/config.toml
2. Run anaconda auth login
3. Add authenticated channels to ~/.condarc
4. Run conda commands normally - authentication should "just work" without manual token passing

Environment

• Domain: stage.anaconda.com
• Channel: https://repo-latest.dev-us-east-1.anaconda.cloud/repo/wheels-test/

Note:
There was a discussion about this in Slack, and @mattkram did debugging on the debug/wheels branch (https://github.com/anaconda/anaconda-auth/tree/debug/wheels), thanks Matt!

[mattkram]

Thanks @danyeaw.

I believe we have two pieces of information that have to be connected to get this working, and I welcome your feedback on how the configuration should look.

First, we need to tell anaconda-auth which auth domain to use for looking up the appropriate credential for a given channel. So for your example, we need to tell the plugin to use stage.anaconda.com as the auth domain for the channel https://repo-latest.dev-us-east-1.anaconda.cloud/repo/wheels-test/. We currently have a hard-coded set of defaults, but those only cover some specific set of production domains and we need to be able to provide additional values via configuration.

Second, for a given channel, absent a server-side signaling mechanism we need to be able to tell the plugin whether to use a legacy repo token, or a modern API key. We already have a configuration variable for this, which was added as a rudimentary feature flag for testing against prod, but we need to refine this a bit more to make it more understandable.

So, I think we have two ways to provide this information. I suspect we should probably do both, but I'd appreciate feedback.

1. Extend the allowable fields in conda's channel_settings. I need to look to see whether this is doable or not. I suspect this is a pretty flexible dictionary lookup based on conda-auth so we can probably do that. This might be something like:

channel_settings:
  - auth: anaconda-auth
    channel: https://repo-latest.dev-us-east-1.anaconda.cloud/repo/wheels-test/
    auth_domain: stage.anaconda.com  # Defaults to anaconda.com
    credential_type: api-key  # Defaults to the associated value corresponding to "use_unified_repo_api_key" below

2. Place this configuration inside ~/.anaconda/config.toml

default_site = "cloud-staging"

[sites."cloud-staging"]
domain = "stage.anaconda.com"
use_unified_repo_api_key = true  # This is the existing variable name
repo_domains = [
  "repo-latest.dev-us-east-1.anaconda.cloud"
]

I think both will work. If we allow both at the same time, we have to then consider conflict scenarios. So FWIW I think Option 2 is easier and more aligned with other non-dev use cases that may come up around self-hosted.

[danyeaw]

Hey @mattkram, thanks so much!

At least for me, being able to put all my channel config in one place with option 1 is preferred. I am admittedly less familiar with the ~/.anaconda/config.toml file, and it creates some dissonance with me if something isn't working to figure out if it is something incorrect with my condarc or this other file. If you think it is important to support both options, that's great as well.

[mattkram]

I think that makes a lot of sense. I'm probably over-indexing here on the self-hosted case.

I'll implement both and see what feels best. .condarc is more explicit so we should have it in either case I think.