---
# System prepended metadata

title: TLS Support for IPA and Node image deployments Study

---

# TLS Support for IPA and Node image deployments Study

This document lists the result of study related to [KB-948 TLS support for IPA deployment and node image deployment](https://jira.nordix.org/browse/KB-948)

[WIP commit](https://github.com/metal3-io/baremetal-operator/commit/e0260a4dd1892e2d5c137c66633abdcf06281f41) is currently a part of `run_local_ironic.sh` script, but can be extracted to be a stand-alone script if needed.

## What this change does

This change injects ironic's and ironic inspector's tls certificates into IPA images, and disable IPA's `insecure` client connection. Ironic's and Ironic Inspector's certs can be generated by setting `IRONIC_TLS_SETUP=true`.

Connections of reverse directions, with IPA acting as a server and `ironic` as client, is automatically TLS secured by default, per [IPA documentation](https://docs.openstack.org//ironic-python-agent/latest/doc-ironic-python-agent.pdf).

The change injected two sets of cafile/certfile/keyfile (one for `ironic` and the other for `ironic-inspector`) and it seems to work. However, IPA documentation said that "Currently a single set of cafile/certfile/keyfile options is used for all HTTP requests to the other services." (It was also confirmed that without either of the two sets, the hosts won't boot).

This injection was confirmed to work with `mixed`, `ipmi`, `redfish` and `redfish-virtualmedia` bootings.

TLS connections towards HTTP image server was not properly tested, as this server has not been configured with tls in our setup. However, as IPA was configured to not accept insecure connect and as the image server uses same ip, hence same tls cert, as `ironic`, this is likely to work once the tls configuration is done for image server.

## Drawbacks
- ~~Currently, for IPA images with password access (built with [`build_ipa.sh`](https://github.com/Nordix/metal3-dev-tools/blob/main/ci/scripts/image_scripts/build_ipa.sh) with `ENABLE_DEV_USER_PASS=true`), the virsh nodes setup with the repackaged image won't accept login. The reason is unknown yet.~~
- The exact TLS version in use has not been investigated. However, as pointed out in [this Stackoverflow thread](https://stackoverflow.com/questions/32310951/how-to-get-the-underlying-socket-when-using-python-requests/32311849#32311849), it's impossible to figure out the exact TLS version used in a connections made with python's `requests` library (which is used by `ipa`). It might be possible to sniff this info (using `wireshark`?) from a live system, though.

## Questions
1. Should we spend more time to investigate steps needed to config TLS on the image server, to verify if connections to that server can also be secured?
2. ~~Should we spend time on investigating issue with the dev user password?~~