You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What hardware/cloud provider/hypervisor is being used to run Ignition?:
Any
Desired Feature
Support skip TLS verify in .ignition.config.merge
Other Information
Motivation
In the Assisted Installer, we're currently pointing that merge field to the MCS HTTP port of 22624 for joining new nodes to a cluster. This is of-course non-ideal security-wise, but we do it for UX reasons (as getting the right certs is difficult for users).
We often get negative feedback about us using port HTTP 22624 because customers / support are often surprised we use this port instead of the normal HTTPS 22623 port, not for security reasons but rather because they allowlist 22623 in their firewalls/network but not 22624, since 22624 is rarely described in OCP documentation.
It would be beneficial for us to have some way to make ignition merge the full ignition from HTTPS endpoints, despite not having the right certs, without error. It's slightly more secure than HTTP (HTTPS, even with fakeable certs, is still better than plain HTTP), and the connection would be made using the "normal" 22623 port, which users already have allowlisted.
Design considerations
Ideally, skipping TLS verification would also be supported in general for other ignition fields that can make HTTP(s) requests.
Having said that, it's important to design this feature in such a way as to still make it granular, and not have some global flag under security.tls. i.e. I might want to .ignition.config.merge to an https endpoint without TLS verification but still have some ignition storage file's content be fetched with https securely with certs verified.
What I have in mind is an insecureSkipTLSVerify boolean (or insecureHTTPSSkipTLSVerify to clarify whether it applies to s3://, gs://, etc schemes or not, should it?), that would be sibling of the hash field that you can already find in the verification section, it's both granular and seems clear/simple enough.
Feature Request
Environment
What hardware/cloud provider/hypervisor is being used to run Ignition?:
Any
Desired Feature
.ignition.config.merge
Other Information
Motivation
In the Assisted Installer, we're currently pointing that merge field to the MCS HTTP port of 22624 for joining new nodes to a cluster. This is of-course non-ideal security-wise, but we do it for UX reasons (as getting the right certs is difficult for users).
We often get negative feedback about us using port HTTP 22624 because customers / support are often surprised we use this port instead of the normal HTTPS 22623 port, not for security reasons but rather because they allowlist 22623 in their firewalls/network but not 22624, since 22624 is rarely described in OCP documentation.
It would be beneficial for us to have some way to make ignition merge the full ignition from HTTPS endpoints, despite not having the right certs, without error. It's slightly more secure than HTTP (HTTPS, even with fakeable certs, is still better than plain HTTP), and the connection would be made using the "normal" 22623 port, which users already have allowlisted.
Design considerations
Ideally, skipping TLS verification would also be supported in general for other ignition fields that can make HTTP(s) requests.
Having said that, it's important to design this feature in such a way as to still make it granular, and not have some global flag under
security.tls
. i.e. I might want to.ignition.config.merge
to anhttps
endpoint without TLS verification but still have some ignition storage file's content be fetched withhttps
securely with certs verified.What I have in mind is an
insecureSkipTLSVerify
boolean (orinsecureHTTPSSkipTLSVerify
to clarify whether it applies tos3://
,gs://
, etc schemes or not, should it?), that would be sibling of thehash
field that you can already find in theverification
section, it's both granular and seems clear/simple enough.cc
@travier @prestist
The text was updated successfully, but these errors were encountered: