document configurable K8s cluster domain for Cert Manager (#1232)

Signed-off-by: Zbynek Roubalik <[email protected]>

content/docs/2.12/operate/security.md

@@ -8,9 +8,17 @@ weight = 100
 
 KEDA uses self-signed certificates for different things. These certificates are generated and rotated by the operator. Certificates are stored in a Kubernetes secret (`kedaorg-certs`) that it's mounted to all KEDA components in the (default) path `/certs`. Generated files are named `tls.crt` and `tls.key` for TLS certificate and `ca.crt` and `ca.key` for CA certificate. KEDA also patches Kubernetes resources to include the `caBundle`, making Kubernetes to trust in the CA.
 
+The KEDA operator is responsible for generating certificates for all the services, certificates are by default generated for following DNS names:
+```
+<KEDA_OPERATOR_SERVICE>                          -> eg. keda-operator
+<KEDA_OPERATOR_SERVICE>.svc                      -> eg. keda-operator.svc
+<KEDA_OPERATOR_SERVICE>.svc.<CLUSTER_DOMAIN>     -> eg. keda-operator.svc.cluster.local
+```
+To change the default cluster domain (`cluster.local`), parameter `--k8s-cluster-domain="my-domain"` on KEDA operator can be used. Helm Charts set this automatically from `clusterDomain` value.
+
 While this is a good starting point, some end-users may want to use their own certificates which are generated from their own CA in order to improve security. This can be done by disabling the certificate generation/rotation in the operator and updating default values in other components (if required). 
 
-The KEDA operator is responsible for generating certificates for all the services, this behaviour can be disabled removing the console argument `--enable-cert-rotation=true` or setting it to `false`. Once this setting is disabled, user given certs can be placed in the secret `kedaorg-certs` which is automatically mounted in all the components or they can be patched to use other secret (this can be done throught helm values too).
+Certificates generation in the KEDA operator can be disabled by removing the console argument `--enable-cert-rotation=true` or setting it to `false`. Once this setting is disabled, user given certs can be placed in the secret `kedaorg-certs` which is automatically mounted in all the components or they can be patched to use other secret (this can be done throught helm values too).
 
 All components inspect the folder `/certs` for any certificates inside it. Argument `--cert-dir` can be used to specify another folder to be used as a source for certificates, this argument can be patched in the manifests or using Helm values. Because these certificates are also used for internal communication between KEDA components, the CA is also required to be registered as a trusted CA inside KEDA components.
 

content/docs/2.13/operate/security.md

@@ -8,9 +8,17 @@ weight = 100
 
 KEDA uses self-signed certificates for different things. These certificates are generated and rotated by the operator. Certificates are stored in a Kubernetes secret (`kedaorg-certs`) that it's mounted to all KEDA components in the (default) path `/certs`. Generated files are named `tls.crt` and `tls.key` for TLS certificate and `ca.crt` and `ca.key` for CA certificate. KEDA also patches Kubernetes resources to include the `caBundle`, making Kubernetes to trust in the CA.
 
+The KEDA operator is responsible for generating certificates for all the services, certificates are by default generated for following DNS names:
+```
+<KEDA_OPERATOR_SERVICE>                          -> eg. keda-operator
+<KEDA_OPERATOR_SERVICE>.svc                      -> eg. keda-operator.svc
+<KEDA_OPERATOR_SERVICE>.svc.<CLUSTER_DOMAIN>     -> eg. keda-operator.svc.cluster.local
+```
+To change the default cluster domain (`cluster.local`), parameter `--k8s-cluster-domain="my-domain"` on KEDA operator can be used. Helm Charts set this automatically from `clusterDomain` value.
+
 While this is a good starting point, some end-users may want to use their own certificates which are generated from their own CA in order to improve security. This can be done by disabling the certificate generation/rotation in the operator and updating default values in other components (if required). 
 
-The KEDA operator is responsible for generating certificates for all the services, this behaviour can be disabled removing the console argument `--enable-cert-rotation=true` or setting it to `false`. Once this setting is disabled, user given certs can be placed in the secret `kedaorg-certs` which is automatically mounted in all the components or they can be patched to use other secret (this can be done throught helm values too).
+Certificates generation in the KEDA operator can be disabled by removing the console argument `--enable-cert-rotation=true` or setting it to `false`. Once this setting is disabled, user given certs can be placed in the secret `kedaorg-certs` which is automatically mounted in all the components or they can be patched to use other secret (this can be done throught helm values too).
 
 All components inspect the folder `/certs` for any certificates inside it. Argument `--cert-dir` can be used to specify another folder to be used as a source for certificates, this argument can be patched in the manifests or using Helm values. Because these certificates are also used for internal communication between KEDA components, the CA is also required to be registered as a trusted CA inside KEDA components.