Automatic merge from submit-queue (batch tested with PRs 37055, 40142)
azure: azure container registry: fix login server
**What this PR does / why we need it**:
Fixes the Azure Container Registry integration
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #
n/a
**Special notes for your reviewer**:
Before this change, if I created an ACR with name `colemicktest`, then the login server would be `colemicktest-microsoft.azurecr.io`. This code was concating to form `colemicktest.azurecr.io` which does not work.
The fix is to reach into RegistryProperties and read out the login server domain name directly.
Also, this should eliminate that existed when ACR gets to sovereign clouds.
**Release note**:
```release-note
azure: fix Azure Container Registry integration
```
Means we can run in newly announced regions without a code change.
We don't register the ECR provider in new regions, so we will still need
a code change for now.
This also means we do trust config / instance metadata, and don't reject
incorrectly configured zones.
Fix#35014
Automatic merge from submit-queue
Curating Owners: pkg/credentialprovider
cc @liggitt @erictune
In an effort to expand the existing pool of reviewers and establish a
two-tiered review process (first someone lgtms and then someone
experienced in the project approves), we are adding new reviewers to
existing owners files.
If You Care About the Process:
------------------------------
We did this by algorithmically figuring out who’s contributed code to
the project and in what directories. Unfortunately, that doesn’t work
well: people that have made mechanical code changes (e.g change the
copyright header across all directories) end up as reviewers in lots of
places.
Instead of using pure commit data, we generated an excessively large
list of reviewers and pruned based on all time commit data, recent
commit data and review data (number of PRs commented on).
At this point we have a decent list of reviewers, but it needs one last
pass for fine tuning.
Also, see https://github.com/kubernetes/contrib/issues/1389.
TLDR:
-----
As an owner of a sig/directory and a leader of the project, here’s what
we need from you:
1. Use PR https://github.com/kubernetes/kubernetes/pull/35715 as an example.
2. The pull-request is made editable, please edit the `OWNERS` file to
remove the names of people that shouldn't be reviewing code in the
future in the **reviewers** section. You probably do NOT need to modify
the **approvers** section. Names asre sorted by relevance, using some
secret statistics.
3. Notify me if you want some OWNERS file to be removed. Being an
approver or reviewer of a parent directory makes you a reviewer/approver
of the subdirectories too, so not all OWNERS files may be necessary.
4. Please use ALIAS if you want to use the same list of people over and
over again (don't hesitate to ask me for help, or use the pull-request
above as an example)
Automatic merge from submit-queue
make invocation ReadDockerConfigFile can handle .dockerconfigjson file
**What this PR does / why we need it**:
When **.docker/config.json** is used to authenticate docker registry, the data key **.dockerconfigjson** should be used if we want to save this kind of docker auth data into a secret. So this PR is mainly to make invocation `ReadDockerConfigFile `have ability to read **.dockerconfigjson** file.
@liggitt
only extract ReadSpecificDockerConfigJsonFile from function ReadDockerConfigJSONFile
put error checking and logging in the loop above
godoc gofmt and return dockecfg directly
Automatic merge from submit-queue
make function ReadDockerConfigFile more flexible
In our code, the public function `ReadDockerConfigFile` looks like not enough flexible:
when I want to use this function to get docker config info from a specific path, I have to call `SetPreferredDockercfgPath`, and then the setting preferredPath will be valid in function `ReadDockerConfigFile`. I know in our code, we call `SetPreferredDockercfgPath` in one place ,then call `ReadDockerConfigFile` in another place, it was not in same context. But it looks like not thread safety.
I think if user who use our code want to get docker config from a specific path, it is reasonable to call directly `ReadDockerConfigFile ` with a dockerconfigPath argument, and it can avoid some scenarios that thread is not safety .
I add a test case for this function.
rename the variable
make parameter more flexible
handle docker config file path
use a single set of paths
delete debug print
gofmt
delete the empty line
comment is not correct
move the comment to the correct place
keep original signature
godoc
Automatic merge from submit-queue
Fix httpclient setup for gcp credential provider to have timeout
The default http client has no timeout.
This could cause problems when not on GCP environments.
This PR changes to use a 10s timeout, and ensures the transport has our normal defaults applied.
/cc @ncdc @liggitt
Automatic merge from submit-queue
Do not query the metadata server to find out if running on GCE. Retry metadata server query for gcr if running on gce.
Retry the logic for determining is gcr is enabled to workaround metadata unavailability.
Note: This patch does not retry fetching registry credentials.
Use constructor for ecrProvider
Rename package to "credentials" like golint requests
Don't wrap the lazy provider with a caching provider
Add immedita compile-time interface conformance checks for the interfaces
Added comments
This is step two. We now create long-lived, lazy ECR providers in all regions.
When first used, they will create the actual ECR providers doing the work
behind the scenes, namely talking to ECR in the region where the image lives,
rather than the one our instance is running in.
Also:
- moved the list of AWS regions out of the AWS cloudprovider and into the
credentialprovider, then exported it from there.
- improved logging
Behold, running in us-east-1:
```
aws_credentials.go:127] Creating ecrProvider for us-west-2
aws_credentials.go:63] AWS request: ecr:GetAuthorizationToken in us-west-2
aws_credentials.go:217] Adding credentials for user AWS in us-west-2
Successfully pulled image 123456789012.dkr.ecr.us-west-2.amazonaws.com/test:latest"
```
*"One small step for a pod, one giant leap for Kube-kind."*
This is step one for cross-region ECR support and has no visible effects yet.
I'm not crazy about the name LazyProvide. Perhaps the interface method could
remain like that and the package method of the same name could become
LateBind(). I still don't understand why the credential provider has a
DockerConfigEntry that has the same fields but is distinct from
docker.AuthConfiguration. I had to write a converter now that we do that in
more than one place.
In step two, I'll add another intermediate, lazy provider for each AWS region,
whose empty LazyAuthConfiguration will have a refresh time of months or years.
Behind the scenes, it'll use an actual ecrProvider with the usual ~12 hour
credentials, that will get created (and later refreshed) only when kubelet is
attempting to pull an image. If we simply turned ecrProvider directly into a
lazy provider, we would bypass all the caching and get new credentials for
each image pulled.
Kris