Show non-admin-enabled Azure container registries in tree

[StephenWeatherford]

No description provided.

[StephenWeatherford]

@fiveisprime, @chrisdias This is the feature that Esteban's PR (#341) is fixing - now non-admin-enabled container registries show up in the tree. Which I assume is a good thing, but... All CLI-driven features like Push will fail for these container registries. Should we allow the PR but show an error if they try to Push etc.?

[fiveisprime]

We talked a little about this last week and I seem to remember concluding that it's possible to use an RBAC service principal to fix the push when the admin user is disabled (#351). What will it take to automate SP auth and get admin disabled pushes working?

Ideally, we wouldn't expose "unsupported" registries to avoid confusion - can we land those together?

[StephenWeatherford]

@estebanreyl Is there a way to set up docker to use an Azure registry container that's not admin-enabled?

[estebanreyl]

It is possible, both with service principals and a refresh token, in fact for the latter I have a working example. As for service principals, not sure how you would set that up for a user but automating auth using the tokens to enable push pull, etc should be easy enough. As a further note, the existing docker extension doesn't really support, admin enabled/non admin enabled registries for purposes of push, in fact in order to make a successful push to ACR people currently need to have the CLI and have done az acr login (I think issue #177 was referring to this). As a result we wouldn't be exposing anything that wasn't already unsupported for push. Going forward we could for example extend docker push, identify if an app is pushing to an azure container registry and if so ask the user if they would like us to login for them using a refresh token allowing push and pull functionality. We are currently working on this as well.