IpmiCredentials

What are IPMI credentials for

Ironic reference driver uses an out of band management channel for power management, node restart and later for low level node monitoring purposes. The management channel is realized with an IPMI session between Ironic conductor and the Baseboard Management Controller (BMC). For channel establishment, Ironic conductor shall pass IPMI authentication procedure using a pre-shared secret. This authentication is needed at every time whenever Ironic connects to the BMC, e.g. power state changes, serial console access or sensor data retrieval.

Configuration in Icehouse release

In the Icehouse release, the security credentials used for IPMI authentication are configured in Ironic Database via the RESTful API. Creation of the IPMI user and storing shared secret at the BMC side shall be performed via an external manner. One way is to use existing monitoring system and create extra credentials for Ironic. Alternatively, manual configuration might be needed.

Automated Configuration

This blueprint describes a procedure for establishing and maintaining trust relationship between Ironic conductor and the management controller of the bare metal nodes in situations where this is not possible via existing monitoring system.

This procedure covers the following uses cases: 1) Generation and sharing a secret on automatic node discovery 2) Generation and sharing a secret on explicit REST API requests 3) Extension of the procedures above when using an external secret store e.g. Barbican is used

The first scenario cannot rely on any pre-existing authentication between Ironic and the BMC. Instead, the BMC-side password configuration is applied by the Ironic Agent, that could be the utility ramdisk running on the node processor, e.g. Ironic Python Agent. As per the IPMI standard, agent from the local processor uses session-less connections and can perform IPMI messaging without authentication.

This BP also offers the same procedure for the second scenario when secret reconfiguration is requested through the REST API. It shall be noted that node configuration via agent is not possible while it is in service. As long as the trust relationship exists between Ironic and BMC, password change might also be possible with out-of-band methods without service disruption, but that method is outside of the scope of this BP.

The third scenario uses Openstack-standard external secret store for generating and storing the secrets instead of using Ironic internal storage. As Barbican is still an incubation project and cannot be assumed to be available in all deployments, therefore the external storage should be optional for a while.

Scenario-1 Password Setting on Automated Discovery

Scenario-1

1. On node discovery, the Ironic Agent informs Ironic on the new node. The actual message format is outside of the scope of this BP. The Discover message is extended with the transport layer (IP) address of the BMC.
2. Ironic conductor is generating a new secret (password) for the node, and stores it in the Ironic DB together with the BMC address.
3. A request is sent to the agent to set the new credentials with extending the utility ramdisk API with a new request.
4. The agent updates the user credentials with the requested secret, using ipmitool or a native IPMI library.

Scenario-2: Set BMC password on API request

Scenario-2

1. Ironic API is extended with a new vendor passthrough method for setting bmc password. The contents of the method could contain optionally a new username and password.
2. If no username and/or password is given, the Ironic generates a new secret and/or uses default username (ironic). The credentials are stored in Ironic DB.
3. A request is sent to the agent to set the new credentials with extending the utility ramdisk API with a new request.
4. The agent updates the user credentials with the requested secret, using ipmitool or a native IPMI library.

Scenario-3: External secret store

It should be configurable on the controller nodes whether internal or external secret store to be used.

Scenario-3

1. Ironic API is extended with a new vendor passthrough method for setting bmc password. The contents of the method could contain optionally an existing secret UUID, in that case steps 2 and 3 are skipped.
2. If no secret UUID is given, the Ironic sends an order to Barbican for requesting a new secret
3. Barbican generates the secret and stores in Secret DB
4. A request is sent to the agent to get the secret
5. The secret UUID is stored in the Ironic DB
6. Set password request is sent to the Ironic Agent
7. The agent updates the user credentials with the requested secret