search

contract-first-idp / platform-components

GitOps manifest for the platform
0 stars 14 forks source link

Add DevSpaces operator to platform manifest #30

Closed smongiar closed 1 month ago

smongiar commented 1 month ago

Currently I have not been found capable of externalizing this certificate, which however, does not seem to me to be sensitive data. So it can also be hardcoded, the problem is that I would have liked to make it configurable, because it can change. In any case, the procedure for any generation is described in this section of the README.

I also talked about it with @rohittaneja0 , maybe in the future he could help me set a _fileParameters_ in the argo manifest of DevSpaces, as reported here

davgordo commented 1 month ago

Hi @smongiar. Thank you for contributing this. Id like to understand the certificate part a little bit better.

The instructions say that we need a self-signed certificate for Che, and if that's the case, then we have the ability to issue certificates with cert-manager.

However, looking a little deeper, it seems the certificate we need is actually GitHub's certificate (or at least the CA) so that we can trust the GitHub API. That is somewhat surprising, given that a major public-facing service would typically use a well-known authority. Taking a look now, it seems Sectigo ECC is the CA. I'm surprised we would have to import it, but perhaps we are very careful with DevSpaces default trust.

Can you confirm which use case applies:

  1. We need a certificate (could be self-signed) for Che's TLS endpoints
  2. We need GitHub's CA in order to trust connections to its API

Perhaps we need both?

smongiar commented 1 month ago

Hi @smongiar. Thank you for contributing this. Id like to understand the certificate part a little bit better.

The instructions say that we need a self-signed certificate for Che, and if that's the case, then we have the ability to issue certificates with cert-manager.

However, looking a little deeper, it seems the certificate we need is actually GitHub's certificate (or at least the CA) so that we can trust the GitHub API. That is somewhat surprising, given that a major public-facing service would typically use a well-known authority. Taking a look now, it seems Sectigo ECC is the CA. I'm surprised we would have to import it, but perhaps we are very careful with DevSpaces default trust.

Can you confirm which use case applies:

  1. We need a certificate (could be self-signed) for Che's TLS endpoints
  2. We need GitHub's CA in order to trust connections to its API

Perhaps we need both?

Hi @davgordo , TBH, I don't know about point (1.), for sure I can use Che's HTTPS endpoints, without anything else strictly needed (at least the links I use to create the workspaces).

Regarding (2.) it could be the case. Without this configuration I was unable to connect to the GitHub server, or more precisely, to read the repository, when Che is looking for the .devfile. I followed this guide. Same in the upstream project. As you mentioned, I was surprised that even this CA-trusted certificate, makes Git repo connections to work.

Anyway, my proposal, is to double-check the functionality using the configurations of cert-manager operator. but I'm not so experienced with that. Did you already give it a try?