update kubeflow dip-catalog

2025-01-13 02:31:27 +00:00
parent 1dc1181a03
commit 5451f16d72
1959 changed files with 602337 additions and 0 deletions
@@ -0,0 +1,43 @@
+# Unauthenticated Issuer Discovery
+
+If you are using Kubernetes with tools like kind, vCluster, minikube, or similar solutions for local
+development, it's highly likely that the Kubernetes OIDC Issuer operates within the cluster and is
+secured with self-signed certificates.
+
+To facilitate the use of m2m tokens with `oauth2-proxy` and Istio, both tools must perform OIDC
+Connect Discovery on the Token Issuer. Kubernetes offers OIDC Discovery functionality at a specific
+URI:
+```
+https://kubernetes.default.svc.cluster.local/.well-known/openid-configuration
+```
+
+Access to this endpoint is blocked by default due to RBAC policies, but it can be enabled by
+creating a `ClusterRoleBinding`. This binding associates the predefined `ClusterRole`
+`system:service-account-issuer-discovery` with the `system:unauthenticated` group. The
+configuration for this is detailed in the resource file `clusterrolebinding.unauthenticated-oidc-viewer.yaml`.
+
+Once this step is completed, the endpoint can be accessed to reveal the Issuer URL:
+```bash
+$ curl -k https://kubernetes.default.svc.cluster.local/.well-known/openid-configuration
+
+# Example output in kind:
+{"issuer":"https://kubernetes.default.svc.cluster.local","jwks_uri":"https://172.18.0.5:6443/openid/v1/jwks","response_types_supported":["id_token"],"subject_types_supported":["public"],"id_token_signing_alg_values_supported":["RS256"]}
+
+# Example output in vCluster:
+{"issuer":"https://kubernetes.default.svc.cluster.local","jwks_uri":"https://1.2.3.4:6443/openid/v1/jwks","response_types_supported":["id_token"],"subject_types_supported":["public"],"id_token_signing_alg_values_supported":["RS256"]}
+
+# Example output in AWS EKS:
+{"issuer":"https://oidc.eks.region.amazonaws.com/id/123abc","jwks_uri":"https://ip-1-2-3-4.eu-central-1.compute.internal:443/openid/v1/jwks","response_types_supported":["id_token"],"subject_types_supported":["public"],"id_token_signing_alg_values_supported":["RS256"]}
+```
+
+If you're operating in a `vCluster`, access to the endpoint specified under `jwks_uri` (for example,
+`https://1.2.3.4:6443/openid/v1/jwks`) is managed separately, and merely creating the previously
+mentioned `ClusterRoleBinding` is insufficient. To circumvent this limitation, you can configure the
+`kube-apiserver` to allow anonymous authentication by setting `--anonymous-auth=true`. This is
+achieved by appending `--kube-apiserver-arg=anonymous-auth=true` to the list of arguments in the
+Helm Chart Values file:
+```yaml
+vcluster:
+    extraArgs:
+    - --kube-apiserver-arg=anonymous-auth=true
+```
@@ -0,0 +1,12 @@
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+  name: unauthenticated-oidc-viewer
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: system:service-account-issuer-discovery
+subjects:
+- apiGroup: rbac.authorization.k8s.io
+  kind: Group
+  name: system:unauthenticated
@@ -0,0 +1,5 @@
+apiVersion: kustomize.config.k8s.io/v1alpha1
+kind: Component
+
+resources:
+- clusterrolebinding.unauthenticated-oidc-viewer.yaml