Use of strings.HasPrefix to check for URL protocol in GCP credentialprovider code

[DangerOnTheRanger]

What happened:

DockerConfigURLKeyProvider.Provide in pkg/credentialprovider/gcp/metadata.go implements fetching an URL embedded in a GCE VM metadata key and reading the dockercfg linked in the URL. strings.HasPrefix is used to check the protocol of the URL. HasPrefix will work for checking against http/https-based URLs, but will also fail to correctly filter strings such as:

• httpstuff
• httpz
• httpinvalid://google.com

What you expected to happen:

The existing error message for unknown/incorrect URL schemes should be returned for the above strings. Either an URL library or some function that would ideally get reused throughout k8s in place of HasPrefix for this sort of thing would be good, as well.

How to reproduce it (as minimally and precisely as possible):

Modifying metadata_test.go to return an incorrect/invalid URL when the test handler receives a request for the contents of the metadata key will work. For instance, modifying line 149 to read:

fmt.Fprint(w, "httpinv://foo.bar.com"+valueEndpoint)

Anything else we need to know?:

Environment:

• Kubernetes version (use kubectl version): 1.20 beta (kubectl version reports git commit 5cfce4e5cb4dc6ff429c088ec25973e2ebae2d86), but the relevant line of code has been around for a while longer than 1.20
• Cloud provider or hardware configuration: GCP
• OS (e.g: cat /etc/os-release):
• Kernel (e.g. uname -a):
• Install tools:
• Network plugin and version (if this is a network-related bug):
• Others:

[DangerOnTheRanger]

/sig cloud-provider

[fejta-bot]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten

[andrewsykim]

/triage accepted

[fejta-bot]

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community. /close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to [this](https://github.com/kubernetes/kubernetes/issues/96965#issuecomment-850676186): >Rotten issues close after 30d of inactivity. >Reopen the issue with `/reopen`. >Mark the issue as fresh with `/remove-lifecycle rotten`. > >Send feedback to sig-contributor-experience at [kubernetes/community](https://github.com/kubernetes/community). >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.