Strategies for rolling out SSH CA host certs

Basically you’re looking to solve the authentication issue in step 6 within the host verification setup instructions, correct?
Or is it steps 5 and 6 (I’m not sure where the host’s public key is coming from here)?

Regardless you have some options:

  1. Use a config management tool like you mentioned previously
  2. Use a common credential (AppRole role_id+secret_id) in your script, which has the obvious drawbacks you mentioned
  3. You could leverage an AppRole role with the bind_secret_id parameter set to false and set the token_bound_cidrs parameter to the list of your authorized host subnets (this may be best paired with the token_no_default_policy to better restrict the capabilities of the token). This method assumes you have a well regulated set of IPs/subnets per target role.
  4. Use the Trusted Orchestrator or similar approach - this would be a bit of a hybrid model where you could include an AppRole role_id in your image then use a tool such as Ansible to drop a secret_id on the target so that only the target has the full credential. Then have the target run the script to auth and pull down the SSH cert. If all you’re aiming to accomplish is the SSH config then this might be a bit overkill but if you’re looking to enable broader Vault usage then this might be an attractive option.

I can’t tell you what’s best for your environment, of course. However, hopefully some of these options help you determine an appropriate solution for your use case.

I’d recommend building a matrix of sorts and poking holes in each of the options and the one that has the least/smallest holes in it would probably be your best bet. You can always add more layers (monitoring/alerting, for instance) to better secure the solution.