-
Task
-
Resolution: Unresolved
-
Undefined
-
None
-
None
-
sat-endeavour
-
5
-
False
-
None
Goal:
- Our customers in regulated environments are asked to use SSH certificates to avoid TOFU model and to be able to re-generate the private key of the Capsule's key efficiently.
- The need for renewing the key is e.g. once a year.
- We need to provide an easy way to use existing SSH CA infrastructure, not necessarily automating the creation and management of it
Acceptance Criteria:
- Customer must be able to provide public key, private key and certificate to the Capsule that should be used for User authentication during the REX connection
- Customer must be able to provide CA certificate that should be trusted when connecting to all target hosts from Capsule.
- Once provided/configured, the Capsule must trust target host certificate if it was signed by the provided CA. The host also needs to successfully authenticate the user without deploying the public key to the authorized_keys file.
- Customer should not setup file permissions and ownership manually, the configuration must be kept also during Satellite upgrade
- Customer must be able to easily reconfigure all 4 assets on the regular basis
- Registration and provisioning flows must configure the sshd on the registered/provisioned machine accordingly
Open questions:
- Do we need to support also only subset of the functionality - Host keys vs User keys?
- Yes - if we don't want to (or can't) orchestrate key signing, we'd have to support only a subset
- Is this the recommended way?
- Depends on customer's requirements, if frequent key rotation is required then yes, otherwise probably not.
- Should this be the default?
- No. It requires the customer to have something extra in place (their own CA), we cannot require that.
- Should this become the only way?
- No, see previous question and answer.
- Does it work with Ansible?
- Yes, it does
- Do we want to provide recommendation on the expiration, use of principals or any other feature of the functionality?
- No. If they have their own CA, they should also have guidelines about its use, we shouldn't reinvent the wheel
- Should Satellite become a CA or should we rely on external, possibly already present, CA?
- External is a must, internal ca might come with responsibilities that we don't want to have, but then again without some flows might not be able to be automated
- No. If the customer already has something in place, we should be able to use it. That's the scope for now.
- What to do when the user key needs to be rotated?
- Generate a key pair, have it signed by the CA, deploy the private key, public key and the certificate to expected locations on the capsule
- What to do when the CA cert needs to be rotated?
- Change the CA cert, deploy the new ca cert to the capsules, deploy the CA cert to all the hosts so that keys signed by it can be trusted
- Is there some sort of a standard that we could rely on when it comes to this?
For the initial research, see the existing KCS
QE Automation Tracker for https://issues.redhat.com/browse/SAT-28038