Azure Contianer Registry login scenario discussion about cli HOT 9 CLOSED

@sajayantony @shhsu I think I understand the flow, but for the benefit of @thaJeztah and @nass, can you help me spell it out? I think it's something like:

1. User installs Docker
2. User uses standard Docker credential helper for their platform
3. User adds azure credential helper
4. User does docker login <some-azure-registry>
5. Docker delegates to azure credential helper
6. azure credential helper prompts user to visit azure device login website (like the azure cli does) and blocks
7. user visits azure device login website, completes login
8. azure credential helper unblocks and docker login completes
9. The resulting azure auth is cached in the standard (non-azure) credential helper

Please correct any of the above that I got wrong.

from cli.

@sajayantony @DavidObando

from cli.

Bringing in @friism since @shhsu got the recommendation to use the credential manager and hit quite a few design issues when enabling interactive login with AAD with the approach as discussed above.
/cc @SteveLasker

from cli.

I'm sorry that I wasn't clear in my first message.

We are also hoping that the user would not need to install azure cli for this scenario. Namely, we want to user to be able to call "docker login" to login to an Azure Container Registry, but the login process would be Azure specific.

I don't think this is a good idea because it means that Docker will carry a bunch of Azure-specific login code. In my previous comment I detailed why I think that's the case:

Imagine, for example, that a security flaw was found in the Azure login flow. With the change you propose in Docker, you'd have to scramble to fix that in Azure tools and CLIs, and you'd have to get a fix into Docker and goad us into action to urgently ship the fix.

If we accepted similar contributions from other registry vendors then that would be hard to scale for us, and if you got similar changes into more software like Docker, it would be equally hard for you to scale fixing problems all the places that implemented Azure login.

Quoting from my previous comment:

Users would configure your credential-helper for a wildcard domain that matches all Azure registries, and then they can start doing docker push/pull without further ado. They just have to be logged in to Azure with azure login (or the PowerShell equivalent).

Please let me know if I missed anything.

from cli.

Thanks @friism
To be clear, we are not doing anything Azure specific in cli and docker-credential-helper. Going back to the list of 3 changes we are requesting to make, their only purpose is to allow a credential-helper to prompt/fetch user credential interactively though.

from cli.

I believe the basic issue with the docker CLI credential manager is its inability to actually do any interactive operation and even if it does and is able to get new credentials the cli would prompt again.
So in short we need an extensibility point in the cli that would allow a any third party providers to prompt/return credentials and the CLI prompt needs to know not to prompt again and delete this to the underlying provider.

from cli.

@friism
This is correct.
Note that our azure auth token has a relatively short timeout period but can be refreshed, in our get operation in azure credential helper, we implemented a refresh mechanism.

Also, I have talked to @DavidObando offline about https://github.com/shhsu/cli-1/blob/v2_credhelper/cli/command/registry.go#L86-L103. As the code stands now, if the user does not provide -u, the cred store credential would always be used and user would never be prompted. While this code works perfectly for us because our cred store always ensure the correct token is returned, it might not be desirable for other cred store implementations:

Suppose in a typical cred store, user password expires. With the old code path, the user can just call azure login <registry> to login again and it would prompt for the new username and password. If my code change is used, the user would need to call azure logout first and then azure login

The new and more complicated proposal is that, if the user does not provide -u, docker would use always use the cred store credential to log in first if exists. Only when the login fails, would user be prompted. Basically login would perform a lot more similar as push, pull, etc..

I am working on that solution currently. I will update the thread once I have finished it.

from cli.

As discussed #139

from cli.

Closing this issue as we able to see a path forward

from cli.