waveclaw
commented
2 years ago This is intentional. A PR will be rejected.
You must bootstrap the install of the CA source but may not have an existing trusted source.
In actually sensitive environment you will need to provide for that yourself. The defaults in this module cannot help you. The admin in that situation must make advanced use of the types and providers. This is heavily covered in the documentation with several examples and use cases.
This module just does subscription management. The CA parts must presume that you are intelligently handling your certificates and trusts. A machine or automated process cannot do that for you.
Securing the bootstrap is a problem outside of the scope of the default path for a process like this. You should address it fully and carefully at the level of securing your systems, not relying upon default behavior of the 'happy path' which matches the defaults for Katello and Satellite installations.
This would also be rejected on the technical merits.
To use an HTTPS endpoint you have to have one or more of:
- trust a random certificate, which can Man-in-the-middle you
- a 3rd party signed certificate who controls your access, usually through payment of money
- pre-share a CA for that TLS certificate at the HTTP/S source
The first case is the default for Katello or Satellite installations. They default to self-signed CAs for both the puppet components and the pulp content management. Configuration Satellite is beyond the scope of this module.
The second case already assumes you are doing customized Satellite installations to leverage a commercial vendor to source your signed certificates.
The last case is the problem of establishing a proper Certificate Authority internal to your organization. Creation and management of a proper CA is far beyond the scope of the subscription-manager module.
In short, why is it HTTP? Because you don't have a trusted HTTPS source yet at that point. The ca_package creates that so cannot use that itself.
Hello,
The installation of the ca_package in the install class is currently perform over a http source.
In sensitive environments not encrypted traffic may be blocked and the installation of that package will not be possible with the module.
Is there a reason to not use https ? Can we force the installation to use a secure protocol ?
If yes, I can provide a PR.