From bee3ec23368cd0ca27355765edaa7e154f44f704 Mon Sep 17 00:00:00 2001 From: Jorge Turrado Date: Thu, 2 Feb 2023 00:47:47 +0100 Subject: [PATCH 1/3] feat: add docs about custom cas Signed-off-by: Jorge Turrado --- content/docs/2.10/operate/security.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/content/docs/2.10/operate/security.md b/content/docs/2.10/operate/security.md index a6fabe493..88568b6aa 100644 --- a/content/docs/2.10/operate/security.md +++ b/content/docs/2.10/operate/security.md @@ -13,3 +13,9 @@ While this is a good starting point, some end-users may want to use their own ce 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). 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. + +## Register your own CA in KEDA Operator Trusted Store + +There are some use cases where the upstream expose self-signed CAs (or other cases like AWS where their CA isn't registered as trusted either). Some scalers allow skipping the cert validation thanks to `unsafeSsl` but this parameter isn't totally integrated and it allows any certificate, which is not totally secure. + +Due to to this, KEDA supports registering custom CAs to be used on all the SDKs where is possible. To register custom CAs, you need to ensure that the certs are in `/custom-cas` folder because KEDA will try to register as trusted CAs all the certificates inside the folder. This can be done with kustomize or helm (using `volumes.keda.extraVolumes` and `volumes.keda.extraVolumeMounts`). From b571ef9eddca87cc62cc76ea9b892a2382f44ecc Mon Sep 17 00:00:00 2001 From: Jorge Turrado Date: Sun, 12 Feb 2023 14:09:05 +0100 Subject: [PATCH 2/3] update folder Signed-off-by: Jorge Turrado --- content/docs/2.10/operate/security.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/2.10/operate/security.md b/content/docs/2.10/operate/security.md index 88568b6aa..8cd9de630 100644 --- a/content/docs/2.10/operate/security.md +++ b/content/docs/2.10/operate/security.md @@ -18,4 +18,4 @@ All components inspect the folder `/certs` for any certificates inside it. Argum There are some use cases where the upstream expose self-signed CAs (or other cases like AWS where their CA isn't registered as trusted either). Some scalers allow skipping the cert validation thanks to `unsafeSsl` but this parameter isn't totally integrated and it allows any certificate, which is not totally secure. -Due to to this, KEDA supports registering custom CAs to be used on all the SDKs where is possible. To register custom CAs, you need to ensure that the certs are in `/custom-cas` folder because KEDA will try to register as trusted CAs all the certificates inside the folder. This can be done with kustomize or helm (using `volumes.keda.extraVolumes` and `volumes.keda.extraVolumeMounts`). +Due to to this, KEDA supports registering custom CAs to be used on all the SDKs where is possible. To register custom CAs, you need to ensure that the certs are in `/custom/ca` folder because KEDA will try to register as trusted CAs all the certificates inside the folder. This can be done with kustomize or helm (using `volumes.keda.extraVolumes` and `volumes.keda.extraVolumeMounts`). From 86a46cbaaccc5cc521e5385f2c964a01c36cd73b Mon Sep 17 00:00:00 2001 From: Zbynek Roubalik Date: Thu, 16 Feb 2023 10:26:02 +0100 Subject: [PATCH 3/3] Update content/docs/2.10/operate/security.md Signed-off-by: Zbynek Roubalik --- content/docs/2.10/operate/security.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/docs/2.10/operate/security.md b/content/docs/2.10/operate/security.md index 8cd9de630..ed0e0d75c 100644 --- a/content/docs/2.10/operate/security.md +++ b/content/docs/2.10/operate/security.md @@ -16,6 +16,6 @@ All components inspect the folder `/certs` for any certificates inside it. Argum ## Register your own CA in KEDA Operator Trusted Store -There are some use cases where the upstream expose self-signed CAs (or other cases like AWS where their CA isn't registered as trusted either). Some scalers allow skipping the cert validation thanks to `unsafeSsl` but this parameter isn't totally integrated and it allows any certificate, which is not totally secure. +There are use cases where we need to use self-signed CAs (cases like AWS where their CA isn't registered as trusted etc.). Some scalers allow skipping the cert validation by setting the `unsafeSsl` parameter, but this isn't ideal because it allows any certificate, which is not secure. -Due to to this, KEDA supports registering custom CAs to be used on all the SDKs where is possible. To register custom CAs, you need to ensure that the certs are in `/custom/ca` folder because KEDA will try to register as trusted CAs all the certificates inside the folder. This can be done with kustomize or helm (using `volumes.keda.extraVolumes` and `volumes.keda.extraVolumeMounts`). +To overcome this problem, KEDA supports registering custom CAs to be used by SDKs where it is possible. To register custom CAs, you need to ensure that the certs are in `/custom/ca` folder and KEDA will try to register as trusted CAs all certificates inside this folder. This can be done with kustomize or helm (using `volumes.keda.extraVolumes` and `volumes.keda.extraVolumeMounts`).