forked from gardener/gardener
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[operator] Manage
plutono
(gardener#8301)
* Add dashboards * Introduce new value `IsGardenCluster` * Add dashboard providers configmap * Add datasource configMap * Add service * Add dashboard configMaps * Add deployment * Add ingress * Move helper function at the end * Deploy oidc dashboard only if authentication webhook is enabled * Integrate plutono in gop flow * Adapt seed plutono * Adapt shoot plutono * Integrate vali * Adapt test * Adapt integration and e2e test * --------------Empty separator commit--------------- * Reuse dashboard among shoot and garden * Change datasource name from `cluster-prometheus` to `prometheus` Update plutono.go * Adapt apiserver-overview dashboard to make it reusable. Rename dashboard variable "apiserver" to "pod" Add 2 variables: job and pod Add the pod variable to the promql expressions * Reuse `apiserver overview` dashboard * Reuse `apiserver` related other dashboard * make default selection all * Reuse apiserver-request-duration-and-response dashboard Old shoot dashboard had some random stuff also * Add pod logs to kubernetes pods dashbboard * Remove Pod file system usage metrics ref - google/cadvisor#2785 * Adapt PC doc * Address review * Use same port for all use case * Drop special handling for OIDC webhook * Allow garden dashboard to have additional dashboards * Adapt test * Use wildcard cert for ingress in runtime cluster * Address review * Address review * Update docs/usage/trusted-tls-for-garden-runtime.md * Update docs/README.md --------- Co-authored-by: Tim Usner <tim.usner@sap.com>
- Loading branch information
Showing
39 changed files
with
20,438 additions
and
1,265 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,42 @@ | ||
# Trusted TLS Certificate for Garden Runtime Cluster | ||
|
||
In Garden Runtime Cluster components are exposed via `Ingress` resources, which make them addressable under the HTTPS protocol. | ||
|
||
Examples: | ||
- Plutono | ||
|
||
Gardener generates the backing TLS certificates, which are signed by the garden runtime cluster's CA by default (self-signed). | ||
|
||
Unlike with a self-contained Kubeconfig file, common internet browsers or operating systems don't trust a garden runtime's cluster CA and adding it as a trusted root is often undesired in enterprise environments. | ||
|
||
Therefore, Gardener operators can predefine a trusted wildcard certificate under which the mentioned endpoints will be served instead. | ||
|
||
## Register a trusted wildcard certificate | ||
Since Garden Runtime Cluster components are published under the ingress domain (`operator.gardener.cloud/v1alpha1.Garden.spec.runtimeCluster.ingress.domain`) a wildcard certificate is required. | ||
|
||
For example: | ||
- Garden Runtime cluster ingress domain: `dev.my-garden.example.com` | ||
- `CN` or `SAN` for a certificate: `*.dev.my-garden.example.com` | ||
|
||
It must be deployed as part of your landscape setup as a Kubernetes `Secret` inside the `garden` namespace of the garden runtime cluster. | ||
|
||
Please ensure that the secret has the `gardener.cloud/role` label shown below: | ||
|
||
```yaml | ||
apiVersion: v1 | ||
data: | ||
ca.crt: base64-encoded-ca.crt | ||
tls.crt: base64-encoded-tls.crt | ||
tls.key: base64-encoded-tls.key | ||
kind: Secret | ||
metadata: | ||
labels: | ||
gardener.cloud/role: controlplane-cert | ||
name: garden-ingress-certificate | ||
namespace: garden | ||
type: Opaque | ||
``` | ||
|
||
## Best Practice | ||
|
||
While it is possible to create the wildcard certificate manually and deploy it to the cluster, it is recommended to let certificate management components (e.g. [gardener/cert-management](https://github.com/gardener/cert-management/)) do this job. |
File renamed without changes.
Oops, something went wrong.