Instruction issue in Chapter 5, section 4

[ckhiem]

Hi guys, 

Just found that, at this section, the lab instruction require you to create a bare configmap used for repo server component to communicate with GIT repo, and label it as "config.openshift.io/inject-trusted-cabundle=true" to use the injected cluster CA (i pretty sure it is served for *.apps.<cluster-name>.<domain> domain), but, the problem is the GIT repo is outside of OCP cluster, and it uses another domain name, not *.apps.<cluster-name>.<domain> domain, resulting to I had get a x509: CA is not trusted error when create an application that links to the Git in ArgoCD. So that, I have to extract the rootCA of Git and create another CM and config it to my repo server, and it worked

Bet you guys also meet this problem. Or if i wrong, please correct me, many thanks lads

[TobyTheHutt · Accepted solution]

Hi @ckhiem 

This seems to be a misunderstanding. Labelling a CM with `config.openshift.io/inject-trusted-cabundle=true` causes that CM to be filled with the trusted CAs of the OpenShift cluster. If you look at the CM after assigning this label, you will see that it contains an extensive list of trusted certification authorities.

See the two chapters in Section 5 "Configuring Trusted Certificates for Git Repository
Access" and "Customizing the Argo CD Web Interface Certificate" where important aspects are explained.

When you configure your ArgoCD instance, you mount this CA-bundle into the repo service (Git). You also define how you want ArgoCD to encrypt its own TLS traffic. It's part of the exercise.

If you keep getting stuck, try resetting the exercise and copy-paste the sample solution from the course. If that works, reverse engineer where you stepped wrong. If the problem persists, leave another comment.

Hope that helps!
Toby

[ckhiem]

Hi Toby,

I appreciate your reply, but I see that "Configuring Trusted Certificates for Git Repository
Access" and "Customizing the Argo CD Web Interface Certificate" are 2 different domains. 

The bare CM labeled with `config.openshift.io/inject-trusted-cabundle=true` will be a volume in the pod gitops-repo-server at path /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem as the instruction in the course. This file will has content of file ca-bundle.crt in CM (list of multiple CA certificates). This pod is the repo server component where you can communicate to Git repository.

About the "Customizing the Argo CD Web Interface Certificate". I see that there is a pod that is the endpoint of service that openshift-gitops-server route target to (so sorry I have forgot the name of pod and service). And this pod is also has its own server certificate, so "ArgoCD to encrypt its own TLS traffic" is another aspect, it is not related to the Cluster CA that is injected to the CM

BTW, I had passed this problem by using another CM that is not labeled with 'config.openshift.io/inject-trusted-cabundle=true' , and I had to extract the rootCA of Git server and add it to my CM => I did not use the ClusterCA of OCP, I used the rootCA of Git server,

Many thanks

[ckhiem]

Hi Toby,

I just found out that the training environment is so perfect, that the rootCA of Git server is also included in OCP cluster CA. So that, the instruction of using CM that is labeled with config.openshift.io/inject-trusted-cabundle=true can work wells. 

So, I have some curiousity about the way that the rootCA of Git is included in OCP clusterCA. I see that the training lab has IDM component that can manage TLS certificate centrally. But how can the rootCA of Git can be included in OCP cluster CA. And, what is form of clusterCA in OCP, is it a secret or configmap of smt like custom resource?

I very appriciate your dedicated response

Many thanks

[TobyTheHutt · Accepted solution]

Hi @ckhiem 

Git CA

The Git URL is `git.ocp4.example.com`. `ocp4.example.com` is the OC cluster domain throughout the entire course. Git does not use a different CA. Git runs within the OC cluster and uses the same CA as any other resource in the cluster.

OC URL semantics

In most of the course, the URLs you use are `something.apps.ocp4.example.com`. The semantics for this is the following:

* "something" is the host label of an OC route

* "apps" is the default ingress subdomain for application routes

* "ocp4" is the cluster name

* "example.com" is the base DNS domain

Your Git URL is "https://git.ocp4.example.com". The "apps" Part is missing, which likely made you think it's not a cluster URL. But everything that points to "*.ocp4.example.com" is something that runs on that OpenShift cluster. URLs in OpenShift are completely configurable.

OC CA bundle

How the OC cluster assembles the CA bundle is complex, but in short: CAs are assembled in the OpenShift OS trust bundle and new certificates can be added by creating a new CM in the `openshift-config` NS. See: https://docs.redhat.com/en/documentation/openshift_container_platform/4.6/html/builds/setting-up-tru...

I hope this helps.

Toby

[Chetan_Tiwary_]

@TobyTheHutt Thanks for clarifying that one - this is very helpful for the learners.

[ckhiem]

Hi Toby, 

You mentiond about *.ocp4.example.com, but actually the level of wildcards (*) is just 1. 

Example, if you create a TLS certificate for *.ocp4.example.com, and your domain is *.apps.ocp4.example.com => it will be invalid. So, I think the TLS certificate in OCP is created for *.apps.ocp4.example.com.

I know that the URL in OCP can be configured, and there are 3 modes of route, but if you chose a hostname that is different from *.apps.<cluster-name>.<domain-name> you have to create another TLS certificate, and somehow, you have to put your own rootCA into the OCP clusterCA, so clusterCA can inject your rootCA into a configmap or secret...

BTW, I appreciate your willing collaboration

Many thanks

[TobyTheHutt]

Oh shambles, sorry for the late reply @ckhiem 

I again think we have a misunderstanding here. The root CA as well as any potential intermediate root CA is not responsible for encryping your TLS traffic. Its job is to generate and sign new TLS certificates which you may then use for that purpose. The restriction you mentioned is therefore not affecting the CA itself, but only the TLS certificates it creates and signs.

These downstream certificates in the chain are used in the TLS communication and they apply to these exact rules you correctly described. The CA however, can create and sign TLS certificates for as many subdomain iterations as the CA admin likes.

Meaning:

The TLS certificates for *.ocp4.example.com AND *.apps.ocp4.example.com are still coming from the same CA which is governing the overall *.ocp4.example.com domain (or maybe even *.example.com, idk because I don't have access to the lab to check).

Lastly, I did not fully understand your sentence:

> "I know that the URL in OCP can be configured, and there are 3 modes of route, but if you chose a hostname that is different from *.apps.<cluster-name>.<domain-name> you have to create another TLS certificate, and somehow, you have to put your own rootCA into the OCP clusterCA, so clusterCA can inject your rootCA into a configmap or secret..."

I do not remember, nor do I see any reason to have different CA in the course lab. But then, maybe this is a confusion of terminology too? You mention "clusterCA" and "rootCA". What do you mean by these two entities and how are they used in your environment?