How are TLS certificates propagated?

[l0rd]

Summary

This is actually a clarification that replaces this issue. It may end up or not in a doc article.

Relevant information

In this doc article it's explained how to import custom TLS certificates in Che so that those are trusted: an admin needs to create configmaps from the CA public certs files and add the following labels:

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

but then it's not clear how Che propagates the certificates in the workspace pod.

1. In what folder of the workspace containers are those certificates mounted?
2. How do we specify TLS key and certificate to be used by Che ingress/routes (and to be trusted too)?
3. How a che-theia plugin or a che editor can trust those certs?
4. What's the self-signed-cert secret for?

[l0rd]

1. In what folder of the workspace containers are those certificates mounted?

When a new workspace is started the following happens:

1. The certs of the ConfigMaps in the Che server namespace (labelled as mentioned above) are copied into a new ConfigMap in the workspace namespace (the new config map is named <workspace-id>-ca-certs)
2. This new ConfigMap is used as a volume named che-ca-certs in the workspace pod
3. The volume che-ca-certs is mounted in folder /public-certs in every container of the pod

[tolusha]

4. What's the self-signed-cert secret for?

For OpenShift

self-signed-certificate secret contains the certificate chain of trust of the OpenShift ingress controller only if self-signed certificate is used.

For Kubernetes

See #19318 (comment)

It is mounted as:

• /tmp/che/secret/ca.crt file in every container of the workspace pod
• CHE_SELF__SIGNED__CERT environment variable into che-server pod and imported into JAVA trust store [1]
• CHE_SELF__SIGNED__CERT environment variable into keycloak pod and imported into keycloak trust store [2] [3]

[1] https://github.com/eclipse/che/blob/master/dockerfiles/che/entrypoint.sh#L325-L329
[2] https://github.com/eclipse-che/che-operator/blob/master/pkg/deploy/identity-provider/deployment_keycloak.go#L115-L118
[3] https://github.com/eclipse-che/che-operator/blob/master/pkg/deploy/identity-provider/deployment_keycloak.go#L162-L168

[tolusha]

@l0rd
I am not sure If understood question 2

@azatsarynnyy
Question 3 is for your team.

[azatsarynnyy]

3. How a che-theia plugin or a che editor can trust those certs?

Che-Theia reads those certificates from a known location (/public-certs) [1]
And then they are used by a particular tool, e.g. axios [2] or some plug-in [3]

[1] https://github.com/eclipse/che-theia/blob/abb6768e3bab88047dd5629fb7546ec9274cd470/extensions/eclipse-che-theia-remote-impl-k8s/src/node/k8s-certificate-service-impl.ts#L29
[2] https://github.com/eclipse/che-theia/blob/abb6768e3bab88047dd5629fb7546ec9274cd470/extensions/eclipse-che-theia-plugin-ext/src/node/che-plugin-service.ts#L181
[3] https://github.com/eclipse/che-theia/blob/abb6768e3bab88047dd5629fb7546ec9274cd470/plugins/workspace-plugin/src/ca-cert.ts#L46

[l0rd]

@tolusha question n.2 is about what happens if an admin sets spec/k8s/tlsSecretName or /spec/server/cheHostTLSSecret:

• Are those secrets propagated to the workspaces?
• What's the difference between these 2 secrets?
• Do they work for k8s only?
• Are they related to self-signed-certificate?

[mmorhun]

2. How do we specify TLS key and certificate to be used by Che ingress/routes (and to be trusted too)?

spec.k8s.tlsSecretName

It is only used for Kubernetes platforms. The default value is che-tls.

1. If field is not empty

1.1. The secret defined in spec.k8s.tlsSecretName doesn't exist

All certificates are generated:

• ca.key is a key file, it is needed to create ca.crt and sign child certificate tls.crt, dropped after the generation is finished.
• ca.crt is a root CA certificate that should be added to user's browser(s).
• tls.key private key that used by Che ingresses to encrypt the connection (should be only on ingress side, sharing it to users is a security risk).
• tls.crt certificate which is shown to user side for the verification (if client has ca.crt then it will trust this endpoint).

The following secrets are created:

• self-signed-certificate (name is hardcoded and cannot be changed) contains only ca.crt. It is mounted into Eclipse Che containers (see How are TLS certificates propagated? #19318 (comment)).
• a secret defined in spec.k8s.tlsSecretName field. The secret contains tls.crt and tls.key. It Is specified in Eclipse Che ingresses config and isn't mounted into any containers.

1.2. The secret defined in spec.k8s.tlsSecretName exists

The secret is used to secure ingresses. It isn't mounted into any containers.
If commonly trusted certificate is NOT used then the self-signed-certificate secret should exist and must contain root CA certificate. It is mounted into Eclipse Che containers
(see #19318 (comment)). If self-signed-certificate secret doesn't exist then root CA certificate must be propagated into Eclipse Che via a configmap: described in docs.

2. If field is empty

All ingresses are secured with default certificates of the ingress controller.
self-signed-certificate secret is created automatically only if self-signed certificate is used (when commonly trusted certificate is used for Che ingresses, then this secret doesn't exists). It is mounted into Eclipse Che containers (see #19318 (comment)).

spec.server.cheHostTLSSecret

It works for both Kubernetes and OpenShift platforms. It is optional and used for user defined (beautified) Che url. It defines secret with similar structure as spec.k8s.tlsSecretName but intended for user defined Che ingress/route (beautiful Che url. It could have different domain, so the first certificate might not match the domain).

Kubernentes

It is supposed that the same root CA is used to created certificates that are stored in secrets defined in spec.k8s.tlsSecretName and spec.server.cheHostTLSSecret.

OpenShift

It is supposed that CA certificate from the certificate chain of trust from ingress controller is used generate certificates that are stored in secret defined in spec.server.cheHostTLSSecret

[nickboldt]

I know nothing about the severity of this issue so I'll just set P1 so that the reporter or SMEs can comment and set the prio appropriately. Yaya round robin by nonSMEs!

[l0rd]

@mmorhun thank you for the detailed explanation. This is useful.

You mentioned that when an administrator specifies spec/server/cheHostTLSSecret the certificate is not propagated to the workspace containers. That means that, in this scenario, communicating from a workspace to Che server components (registries, che-server, keycloak) using external URL will not work right?

[themr0c]

Referenced in https://issues.redhat.com/browse/RHDEVDOCS-2841

[tolusha]

@l0rd
We updated both comments.

• How are TLS certificates propagated? #19318 (comment)
• How are TLS certificates propagated? #19318 (comment)

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.