Open jorgemoralespou opened 2 years ago
cfergeau
commented
2 years ago Relevant OpenShift documentation would be https://docs.openshift.com/container-platform/4.11/security/certificates/replacing-default-ingress-certificate.html and https://docs.openshift.com/container-platform/4.11/security/certificates/api-server.html Not sure if I'm missing other user-visible certs.
jorgemoralespou
commented
2 years ago When using a custom CA for accessing the registry, you must also ensure the container runtime on the host can trust certificates from this CA. I use this for injecting the ca in containerd. Similar should be done in OpenShift for cri-o if that's the container runtime in use.
gbraad
commented
2 years ago I understand your suggestion:
Generate a CA for the user and register it within their OS
... and we have considered something. We have an issue to handle the certificates in general to (as they are identical to everyone) personalize them, however at the moment this is not a priority.
It would be ideal if, as a user, I could provide my own CA
providing a set of CA and associated certificates is far more important than the generation phase. As the certificate should also be imported on the host machines. This is pretty much also a corporate flow, and in that case they prefer to supply/import than to generate
jorgemoralespou
commented
2 years ago @gbraad while I agree with you when talking about corporate CAs, I think that, as an individual contributor/developer using CRC, the experience is not optimal as there's a lot of self-signed certificates around. I would like the tool (CRC here) to be the one taking care of doing everything for me, as I might not be an advanced user to do something similar to what is described in the blog or what can be found in the documentation.
The gist of the ask is that most of the solution is 90% similar if, as a corporate user you provide a reference to the "already registered in your computer" CA that your company provides, as to when as a developer you just want a seamless experience when working with OpenShift and not having all the problems inherent to self-signed certs. Think that most users (developers), when working with a cloud installation of Openshift will not need to care about the certificates as the cluster will most likely be configured in a way that trust is achieved between the developer's computer and the cluster.
CRC has evolved quite a lot but this is still a pain point for users (of role type "developer"), as it makes things more complicated than it should.
Thanks anyways for any consideration for this RFE and I'll be keeping an eye open for when you have time for it.
May the force be with you!
gbraad
commented
2 years ago I would like the tool (CRC here) to be the one taking care of doing everything for me,
It might be an option to generate the certificates, as import/use them is something that needs to happen anyway.
so from a breakdown I would see:
I understand that stricter security policies can be severly impacted when self-signed is used. While a configuration issue, I do understand that a shared set of certificates can help with debug sessions for https or wss.
ctron
commented
2 years ago When creating #3391 I was pointed to this issue instead. I think this issue here is however the other way round, unless I misunderstood it.
I would like CRC to create and manage the certificate for me. But have the created certificate stored on the host machine, exposing the information where it is. So that I can add this manually to any browser, system, library, configuration that I think make sense (for me).
jorgemoralespou
commented
2 years ago @ctron While I see what you're asking and somehow is different, I think that having to import every generated certificate that CRC creates internally and register those in every tool you use (browser, CLI,...) is a bit of additional work. This issue what requests is that:
This will still prevent any other third party accessing a CRC instance in my host to trust CRC generated certs.
This should be a zeroconf feature, where the user will need to do nothing for everything to work out of the box with SSL enabled everywhere, which IMHO is more desirable (user experience wise)
jorgemoralespou
commented
2 years ago @gbraad I'm no longer deeply familiar with OpenShift internals, but there has to be some mechanism already in OpenShift to use a "user provided CA" for everything accessible, as this is a common scenario on private deployments. If that mechanism existed, then it would be a matter of automating generation and registration of a CRC CA on the host (based on the OS), and delete it when deleting the CRC instance. Seems as @cfergeau has linked to some docs (https://github.com/code-ready/crc/issues/3388#issuecomment-1280807672) although seems more complicated than expected.
What's the stance of CRC team on creating your own operators for some of this CRC related work?
ctron
commented
2 years ago @jorgemoralespou Maybe I understood this request wrong, or maybe even @gbraad did. Anyway, It looks to me as if this isn't too far apart.
- CRC creates a CA that is registered in your host OS so that CLI, browser, etc.. will use/trust it by default
This is basically what I am looking for. Without the automation part. I agree, that might be nice for some people. Especially if you are new to this topic. However, from a security point of view, it may be concerning.
Adding a trust anchor to the system (and CRC might not fully understand the system) would mean that CRC is in power to possibly verify each remote peer the user contacts. True, all other trust anchors can do the same, but they might be more trusted than the CRC generated ones.
So just having access to those certs might be good already for a number of use cases, without compromising the setup of the user. Additionally, maybe CRC also cannot be aware of all the tools the user uses. So just giving access to this certificate/trust anchor would enable the user to take care of this.
gbraad
commented
2 years ago The CA generated will need to be imported. In a corporate environment it will most likely already be imported/supplied on the host, so I assume this is not an action we can take per se, hence I mentioned it is import first into the cluster from my POV. Host actions we can most likely not easily automate for this as eg on Windows this requires user interaction.
CRC creates a CA that is registered in your host OS so that CLI, browser, etc.. will use/trust it by default CRC generates every certificate inside the VM with this CA so that trust between host and CRC is given
That is the solution I also see, but we haven't looked into this 'import' phase yet. We need to undertand which certificates need to be replaced.
ctron
commented
2 years ago Exactly! However, a simple first step could be to give the user access to those certificates. So that they can take care of that themselves!
gbraad
commented
2 years ago The certificates that are currently used should not be shared. They are generated during the initial setup phase opf the bundle and are shared among all installed instances. Using these and allow the import/recognization of trust for these is not ideal.
a simple first step could be to give the user access
And that is the problem. At the moment this is not a simple step. We need to investigate which need to be changed, and if changed if the cluster will recognize them properly.
gbraad
commented
2 years ago What's the stance of CRC team on creating your own operators for some of this CRC related work?
Preferably not... however when necesary we do. Recently we included a modified MCO to handle the extended (1 year) internal cluster certificates, who otherwise would be limited to 30 days and cause certificate rotation issues, such as increased start-up time. We have postponed to do this for a long time, hopeing we could convince OpenShift engineering to allow this to be configured, but since the impact of tis became worse over time, especially for the Instruqt team, we decided to override this.
ctron
commented
2 years ago They are generated during the initial setup phase opf the bundle and are shared among all installed instances. Using these and allow the import/recognization of trust for these is not ideal.
That sounds like a simple approach to me. True, it is no ideal. But much more ideal than to click away every security warning the browser gives you. Or disable TLS in all applications that want to talk to CRC hosted services.
gbraad
commented
2 years ago True, it is no ideal.
Not ideal and a possible risk. The user would have to 'trust' the CA and certificates. Each bundle would have to perform the same steps. This causes multiple 'trusted' certificates to litter the machine, and worse easy to be exploited as these are publicly available. I can and will not get a sign-off from the security team on this.
ctron
commented
2 years ago Ok I wasn't aware that the images (bundles) come with pre-generated certificates. I was under the impression they get created during the set up of the instance, like .e.g. minikube does it.
So yes, if you are publishing the CA certificate and key, then that would be a problem.
jorgemoralespou
commented
2 years ago I'm not sure about what security problems you see. If CRC creates a CA that is registered in your host OS and then it's used only in the CRC instance and deleted when the CRC instance is deleted, where is there any potential security flaw?
If the risk you see is that some companies would not allow having CRC creating that CA, then as an alternative, CRC can provide (in this case) the user with detailed instructions on how to generate the CA themselves and configure CRC to use it for the cluster.
This CA, being installed on the host and used within the cluster would give the host machine full trust with the cluster (not the other way around), the cluster would still not be able to access the host on any possible way.
I can see that OpenShift is not meant to use a corporate CA in an easy way (although I would not understand it since this is a common scenario in multiple enterprises where the usage of a corporate CA is mandated), or that CRC because of how it's built can't replace the CA (and roll out new certs) on an existing cluster. I understand this is easier if/when the cluster is being created.
Anyways, I thought this is a cool feature, since this is something I use heavily with minikube and gives me a much leaner experience than the one I get with OpenShift, despite all the other benefits of OpenShift.
gbraad
commented
2 years ago I see a security problem with using the CA and certificates from the initial phase (from the VM) as suggested to give acces to.
From: Jorge Morales Pou @.> Sent: Saturday, October 22, 2022 12:30:14 AM To: code-ready/crc @.> Cc: Gerard Braad @.>; Mention @.> Subject: Re: [code-ready/crc] [RFE] Support user provided CA for internal certificates (Issue #3388)
I'm not sure about what security problems you see. If CRC creates a CA that is registered in your host OS and then it's used only in the CRC instance and deleted when the CRC instance is deleted, where is there any potential security flaw?
If the risk you see is that some companies would not allow having CRC creating that CA, then as an alternative, CRC can provide (in this case) the user with detailed instructions on how to generate the CA themselves and configure CRC to use it for the cluster.
This CA, being installed on the host and used within the cluster would give the host machine full trust with the cluster (not the other way around), the cluster would still not be able to access the host on any possible way.
I can see that OpenShift is not meant to use a corporate CA in an easy way (although I would not understand it since this is a common scenario in multiple enterprises where the usage of a corporate CA is mandated), or that CRC because of how it's built can't replace the CA (and roll out new certs) on an existing cluster. I understand this is easier if/when the cluster is being created.
Anyways, I thought this is a cool feature, since this is something I use heavily with minikube and gives me a much leaner experience than the one I get with OpenShift, despite all the other benefits of OpenShift.
— Reply to this email directly, view it on GitHubhttps://github.com/code-ready/crc/issues/3388#issuecomment-1287188098, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAAOZWCGHB7TAEUJCEJLXDWELAJNANCNFSM6AAAAAARG6IDNY. You are receiving this because you were mentioned.Message ID: @.***>
When using CRC one of the most annoying things that I have to deal with is the fact that all "user facing" certificates are self-signed. I have to keep accepting the usage or configure my tools with additional flags in order to properly work and develop apps using CRC. It would be ideal if, as a user, I could provide my own CA so that the cluster will generate certificates with it for things like the registry, the console,... so that trust between CRC and my machine is achieved. I have detailed the process for minikube here.
The idea is:
As a user, everything will work between their machine and CRC in a secure way out of the box. No more prompts in the browser or more additional flags in the tools.