Replace CI/Zuul references with manual commands in HSM adoption docs#1392
Conversation
The Key Manager (Barbican) HSM adoption documentation contained references to CI-specific tooling (Zuul job vars, CI framework configuration, cifmw_* variables) that are not applicable to users performing adoption manually. This made the Proteccio HSM procedure (section 4.4.2) impossible to follow as a user. Replace CI-oriented instructions with concrete manual commands (oc create secret, oc patch) following the same pattern used by the simple_crypto adoption procedure (section 4.3). Update related concept modules and troubleshooting procedures to remove CI references and use user-facing terminology throughout. Signed-off-by: Mauricio Harley <mharley@redhat.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
| * Uses the enhanced `barbican_adoption` role with HSM awareness | ||
| * Configures HSM integration through a simple boolean flag (`barbican_hsm_enabled: true`) | ||
| * Automatically creates required Kubernetes secrets (`hsm-login` and `proteccio-data`) | ||
| * Patches the `OpenStackControlPlane` CR with HSM-enabled configuration |
There was a problem hiding this comment.
| * Patches the `OpenStackControlPlane` CR with HSM-enabled configuration | |
| * Patches the `OpenStackControlPlane` custom resource with HSM-enabled configuration |
| * Supports both simple crypto and HSM back ends in the target environment | ||
| * Requires HSM-specific configuration variables and custom container images with HSM client libraries (built using the `rhoso_proteccio_hsm` Ansible role) | ||
| * Uses HSM client certificates and configuration files accessible via URLs | ||
| * Requires custom container images with HSM client libraries (built using the `rhoso_proteccio_hsm` Ansible role) |
There was a problem hiding this comment.
| * Requires custom container images with HSM client libraries (built using the `rhoso_proteccio_hsm` Ansible role) | |
| * Requires custom container images with HSM client libraries that are built by using the `rhoso_proteccio_hsm` Ansible role |
| @@ -21,4 +21,4 @@ The {key_manager} supports HSM integration through the PKCS#11 plugin. This enab | |||
| * Compliance with security requirements for production environments | |||
| * Preservation of existing HSM-protected secrets during adoption | |||
|
|
|||
There was a problem hiding this comment.
@mauricioharley This module is not currently included in the adoption guide. If there is value in including this, we should add it to the "assembly_rhoso-180-adoption-overview.adoc" assembly.
| * Preservation of existing HSM-protected secrets during adoption | ||
|
|
||
| HSM integration is configured through a simple boolean flag (`barbican_hsm_enabled`) during the adoption process. For environments that require HSM integration during adoption, see xref:adopting-key-manager-service-with-proteccio-hsm_{context}[Adopting the {key_manager} with Proteccio HSM integration]. | ||
| For environments that require HSM integration during adoption, see xref:adopting-the-key-manager-service-with-proteccio-hsm_{context}[Adopting the {key_manager} with Proteccio HSM integration]. |
There was a problem hiding this comment.
| For environments that require HSM integration during adoption, see xref:adopting-the-key-manager-service-with-proteccio-hsm_{context}[Adopting the {key_manager} with Proteccio HSM integration]. | |
| For environments that require HSM integration during adoption, see xref:adopting-the-key-manager-service-with-proteccio-hsm_hsm-integration[Adopting the {key_manager} with Proteccio HSM integration]. |
| ---- | ||
|
|
||
| . If you are not using the automated adoption, create HSM-specific secrets in the target environment: | ||
| . Create HSM-specific secrets in the target environment: |
There was a problem hiding this comment.
Does "target environment" refer to RHOSO? If so, we could be more specific and use the {rhos_acro} attribute (renders as "RHOSO").
|
|
||
| Without proper HSM configuration, your HSM-protected secrets become inaccessible after adoption. | ||
| * The HSM partition name, MKEK label, and HMAC label match the values configured in your source environment. | ||
| * The Proteccio client certificates and configuration files are valid for the target environment. |
There was a problem hiding this comment.
You could add "...source environment (RHOSP)" and "...target environment (RHOSO)" to be more explicit.
| # Enable HSM integration for the Barbican adoption role | ||
| barbican_hsm_enabled: true | ||
| + | ||
| If you see the `[p11_crypto_plugin]` section with Proteccio-specific settings, for example `library_path = /usr/lib64/libnethsm.so`, continue with the HSM adoption. |
There was a problem hiding this comment.
What if the customer doesn't see the settings?
| `<path_to_client_key>`:: | ||
| Specifies the path to the HSM client key file. | ||
| `<hsm_server_cert_filename>`:: | ||
| Specifies the filename of the HSM server certificate as expected by the Proteccio client, for example, `10_8_60_93.CRT`. |
There was a problem hiding this comment.
| Specifies the filename of the HSM server certificate as expected by the Proteccio client, for example, `10_8_60_93.CRT`. | |
| Specifies the filename of the HSM server certificate that is expected by the Proteccio client, for example, `10_8_60_93.CRT`. |
| .Procedure | ||
|
|
||
| . Edit your hardware security module configuration in the Zuul job vars or CI framework configuration file. | ||
| . Check the `OpenStackControlPlane` CR patch and the Kubernetes secrets that you created during the adoption procedure. |
There was a problem hiding this comment.
| . Check the `OpenStackControlPlane` CR patch and the Kubernetes secrets that you created during the adoption procedure. | |
| . Check the `OpenStackControlPlane` custom resource (CR) patch and the Kubernetes secrets that you created during the adoption procedure. |
| "msg": "No HSM configuration found - using standard adoption" | ||
| } | ||
| ---- | ||
| If the {key_manager_first_ref} does not detect the hardware security module (HSM) configuration after adoption, verify that the HSM configuration exists in the source environment and that the `OpenStackControlPlane` CR includes the correct HSM settings. |
There was a problem hiding this comment.
| If the {key_manager_first_ref} does not detect the hardware security module (HSM) configuration after adoption, verify that the HSM configuration exists in the source environment and that the `OpenStackControlPlane` CR includes the correct HSM settings. | |
| If the {key_manager_first_ref} does not detect the hardware security module (HSM) configuration after adoption, verify that the HSM configuration exists in the source environment and that the `OpenStackControlPlane` custom resource (CR) includes the correct HSM settings. |
Problem
The Key Manager (Barbican) HSM adoption documentation contained references to CI-specific tooling (Zuul job vars, CI framework configuration, cifmw_* variables) that are not applicable to users performing adoption manually. This made the Proteccio HSM procedure (section 4.4.2) impossible to follow as a user.
Replace CI-oriented instructions with concrete manual commands (oc create secret, oc patch) following the same pattern used by the simple_crypto adoption procedure (section 4.3). Update related concept modules and troubleshooting procedures to remove CI references and use user-facing terminology throughout.
Solution
Rewrite the Proteccio HSM procedure (section 4.4.2) to follow the same manual approach used by the simple_crypto adoption procedure (section 4.3): explicit
oc create secretandoc patch openstackcontrolplanecommands with documented replaceable parameters.