Implement addition CA config maps merge and propagation to Che server

[mmorhun]

Signed-off-by: Mykola Morhun mmorhun@redhat.com

What does this PR do?

This PR merged all config maps with CA certificates that marked with che-ca-certs:true label into single config and then pass resulting config map to Che server.
spec.server.serverTrustStoreConfigMapName CR field is supported too and the config map, if any, added into resulting one as well.

What issues does this PR fix or reference?

eclipse-che/che#17634

How to test

1. Deploy Eclipse Che
2. Create a few config maps in che namespace with CA certs
3. Mark some of them with app.kubernetes.io/component:ca-bundle and app.kubernetes.io/part-of:che.eclipse.org labels
4. Start a workspace, check /public-certs folder

To generate CA certs, one may use the following script:

#!/bin/bash

# CA certs generator

OPENSSL_CNF='/etc/pki/tls/openssl.cnf'
if [ ! -f $OPENSSL_CNF ]; then
    OPENSSL_CNF='/etc/ssl/openssl.cnf'
fi

for ((i=1;i<=5;i++)); do
  openssl genrsa -out ${i}.key 4096
  openssl req -batch -new -x509 -nodes -key ${i}.key -sha256 -subj /CN="TestCA${i}" -days 1024 -reqexts SAN -extensions SAN -config <(cat ${OPENSSL_CNF} <(printf '[SAN]\nbasicConstraints=critical, CA:TRUE\nkeyUsage=keyCertSign, cRLSign, digitalSignature')) -outform PEM -out ${i}.crt
done

Then create config maps:

kubectl create configmap ca1 --from-file=1.crt -n che
kubectl create configmap ca23 --from-file=2.crt --from-file=3.crt -n che
kubectl create configmap ca4 --from-file=4.crt -n che
kubectl create configmap ca5 --from-file=5.crt -n che

Finally, add the label:

kubectl label configmap ca1 app.kubernetes.io/part-of=che.eclipse.org -n che && kubectl label configmap ca1 app.kubernetes.io/component=ca-bundle -n che
kubectl label configmap ca23 app.kubernetes.io/part-of=che.eclipse.org -n che && kubectl label configmap ca23 app.kubernetes.io/component=ca-bundle -n che

and/or patch CR:

spec:
  server:
    serverTrustStoreConfigMapName: ca5

It is expected, then certs from ca1, ca23 and ca5 will be propagated into a workspace under /public-certs directory. ca4 should not be propagated.

[mmorhun]

@l0rd do you have some corrections for label name?

[l0rd]

@l0rd do you have some corrections for label name?

@mmorhun yes :-)

I think that we have agreed using recommended kubernetes labels with platform team. cc @skabashnyuk. See in docs. In this case I would use the following labels:

app.kubernetes.io/part-of: che.eclipse.org
app.kubernetes.io/component: ca-bundle

[mmorhun]

@l0rd do you mean that Che admin should add 2 labels to a config map in order to have it recognized by Che as trusted CA source?

[l0rd]

@mmorhun yes, that's consistent with secrets that we want to be injected in workspaces.

[mmorhun]

@l0rd done

[tolusha]

app.kubernetes.io/part-of=che.eclipse.org

[mmorhun]

I wanted to warn users not to edit the config map. But if you think that it is redundant, then I'll delete the label.

[openshift-ci-robot]

New changes are detected. LGTM label has been removed.