We can indirectly retrieve the kube-cross version from the
`build/build-image/cross/VERSION` for the sample-apiserver. This allows
us to simplify the handling in `build/dependencies.yaml` as well as
the required approval (via `OWNERS`) if the kube-cross version changes.
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
Update dependencies and the test images to use pause 3.5. We also
provide a changelog entry for the new container image version.
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
docker buildx CLI plugin is not default enable most functionality which we
comsumed during build releases. Means `docker buildx build` will work, but
flags like `--load` or `--platform` is not supported. Which is still true
statement with most up-to-date docker version. That means for new join
member who plan to build by themself, will need to notice if buildx is
properly installed. And not getting confused by build script when docker
complant about unknown flag `--load`, `--platoform`. Hance, add buildx
instruction to note.
- Cleans up some of the image registry handling by
initializing values in a more consistent and clear
manner.
- Adds the Docker library registry to the list of
values that is override-able.
- Adds a few branches to logic to ensure each registry
is handled the same.
The conformance test for ServiceAccountIssuerDiscovery is currently
configured with --in-cluster-discovery, which only supports token
validation against in-cluster endpoints. Many cloud providers provide
their own, external endpoints for OIDC discovery, and because the iss
claim in tokens will point to these endpoints, but the client in this
test only trusts the Cluster CA, it will fail to connect to the external
discovery endpoints when validating the token.
To ensure that the conformance test at least supports scenario where
both the discovery doc endpoint and JWKS endpoint are cluster-local and
the scenario where both endpoints are cluster-external, this PR has the
test try both and requires at least one to pass.
Caveat: The test still won't support a configuration where one
endpoint is cluster-local and the other is external. We don't yet have
evidence that this is a configuration that is used in practice, so this
initial hotfix will at least fix the conformance test for the "both
external" configuration we know providers already use. Note that if one
endpoint is cluster-local, and the other is cluster-external, tokens can
still only be validated in-cluster, because both endpoints must be
accessible to Relying Parties that validate tokens.
kube-cross:v1.16.3-1 contains x86_64-w64-mingw32, which will allow us to
build Windows binaries. With this, we won't have to rely on the dockerhub
image dockcross/windows-static-x64.
