When constructing the host address string, the address is
not wrapped in square brackets. This does not work in IPv6
Kubernetes deployments. This commit adds square brackets
around the address. IPv4 was also tested to ensure it works
with wrapped address.
Signed-off-by: Jerry Sun <jerry.sun@windriver.com>
Third Party Resources (TPR) have been removed from Kubernetes for
roughly 2 years. This commit removes the support dex had for them.
Documentation has been updated to reflect this and to instruct users
on how to migrate from TPR-powered dex environment to a Custom Resource
Defintion (CRD) based one that dex > v2.17 will support
PR #815 fixed the Kubernetes storage implementation by correctly
returning storage.ErrAlreadyExists on POST conflicts. This caused a
regression in TPR creation (#822) when some, but not all, of the
resources already existed. E.g. for users upgrading from old
versions of dex.
Fixes#822
ghodss/yaml converts from YAML to JSON before attempting to unmarshal.
This allows us to:
* Get the correct behavor when decoding base64'd []byte slices.
* Use *json.RawMessage.
* Not have to support extravagant YAML features.
* Let our structs use `json:` tags
Use a hash algorithm to match client IDs to Kubernetes object names.
Because cryptographic hash algorithms produce sums larger than a
Kubernetes name can fit, a non-cryptographic hash is used instead.
Hash collisions are checked and result in errors.
Using the default KUBECONFIG environment variable to indicate that
the Kubernetes tests should be run lead to cases where developers
accidentally ran the tests. This has now been changed to
"DEX_KUBECONFIG" and documentation hsa been added detailing how to
run these tests.
Additionally, no other storage reads environment variables for its
normal configuration (outside of tests) so the Kubernetes storage
no longer does.
Overall, be less surprising.
These status codes spam the error logs for events like key rotation
and third party resource creation. In these cases "bad" status codes
are expected and shouldn't be automatically printed.
The in cluster kubernetes client currently requires using the
downward API to determine its namespace. However this value can be
determine by inspecting the service account token mounted into the
pod. As a fallback, use this to guess the current namespace.
