Change Details

The cloud-cumin hosts have been configured and in theory should allow users to run any-cookbook but be restricted to only running them on cloud hosts. however there are still some gaps this task intends to document those gaps and ideally try to fix them. === OOB access === From previous talks i think one of the biggest gaps relates to any cookbook that needs the management password, this would include the reimage, firmware-upgrade, provision, decommission, sel, and ipmi-password-reset cookbooks. It seems to me that one easy way to fix this is to have separate OOB passwords for wmcs servers? === Puppetca access === The next issue is that some jobs interact with the puppet ca. the re-image, decommission and renew-certs cookbooks use this functionality. The cookbooks essentially use the `pupet ca` command line to destroy or renew the puppet agent certificate. One way we could fix this is to instead us the [[ https://www.puppet.com/docs/puppet/7/server/http_api_index.html#ssl-certificate-related-services | puppet CA api ]] to manage certificates. on the puppetserver side we can update the auth rules so clod-cumin hosts are only able top preform actions on cloud hosts. This is not something we have done before however it should be doable but id recommend waiting until production has been migrated to puppet7. Another option here would be for WMCS to have there own puppetserveres/dbs Theses are the main blockers im aware of but please comment with any more

~~The cloud-cumin hosts have been configured and in theory should allow users to run any-cookbook but be restricted to only running them on cloud hosts. however there are still some gaps this task intends to document those gaps and ideally try to fix them.~~ **EDIT March 2024:** to make this task more actionable, I'm adding the following Definition of Done: **it should be possible to reimage a cloud server from a cloudcumin**. Solving this will probably unlock other operations as well. === OOB access === From previous talks i think one of the biggest gaps relates to any cookbook that needs the management password, this would include the reimage, firmware-upgrade, provision, decommission, sel, and ipmi-password-reset cookbooks. It seems to me that one easy way to fix this is to have separate OOB passwords for wmcs servers? === Puppet CA access === The next issue is that some jobs interact with the puppet CA. The re-image, decommission and renew-certs cookbooks use this functionality. The cookbooks essentially use the `puppet ca` command line to destroy or renew the puppet agent certificate. One way we could fix this is to instead us the [[ https://www.puppet.com/docs/puppet/7/server/http_api_index.html#ssl-certificate-related-services | puppet CA api ]] to manage certificates. On the puppetserver side we can update the auth rules so cloudcumin hosts are only able to perform actions on cloud hosts. This is not something we have done before however it should be doable but I'd recommend waiting until production has been migrated to puppet7. Another option here would be for WMCS to have there own puppetservers/dbs.

~~The cloud-cumin hosts have been configured and in theory should allow users to run any-cookbook but be restricted to only running them on cloud hosts. however there are still some gaps this task intends to document those gaps and ideally try to fix them.~~ **EDIT March 2024:** to make this task more actionable, I'm adding the following Definition of Done: **it should be possible to reimage a cloud server from a cloudcumin**. Solving this will probably unlock other operations as well. === OOB access === From previous talks i think one of the biggest gaps relates to any cookbook that needs the management password, this would include the reimage, firmware-upgrade, provision, decommission, sel, and ipmi-password-reset cookbooks. It seems to me that one easy way to fix this is to have separate OOB passwords for wmcs servers? === Puppetca CA access === The next issue is that some jobs interact with the puppet ca. tCA. The re-image, decommission and renew-certs cookbooks use this functionality. The cookbooks essentially use the `puppet ca` command line to destroy or renew the puppet agent certificate. One way we could fix this is to instead us the [[ https://www.puppet.com/docs/puppet/7/server/http_api_index.html#ssl-certificate-related-services | puppet CA api ]] to manage certificates. onOn the puppetserver side we can update the auth rules so clod-cloudcumin hosts are only able top preto perform actions on cloud hosts. This is not something we have done before however it should be doable but idI'd recommend waiting until production has been migrated to puppet7. Another option here would be for WMCS to have there own puppetserveres/dbs Theses are the main blockers im aware of but please comment with any moreAnother option here would be for WMCS to have there own puppetservers/dbs.