pki-bot
commented
4 years ago Comment from mharmsen (@mharmsen) at 2014-08-26 04:13:57
After certain alterations, the following was copied from the now defunct ticket PKI TRAC Ticket 1118 - Move 'pkispawn' to a separate package to allow remote access:
- The 'pkispawn' executable will be decoupled into two parts, 'pkispawn' and 'pkideploy' where:
- To prevent any disruption to existing products which integrate it, the 'pkispawn' executable will remain the CLI utilized to install and configure a PKI instance but will only consist of the portion which gathers all of the information for an instance and creates the master Python dictionary; additionally, 'pkispawn' will now always perform the generation of the client Admin keys and produce a CSR for the Admin certificate. Since the 'pkispawn' executable will now be allowed to be run remotely, it will no longer be contained within the 'pki-server' package. However, it will probably need to package the '/etc/pki/default.cfg' file. Per discussions, it was determined that it would be moved to the 'pki-tools' package, and exist as a dependency of the 'pki-server' package.
- The 'pkideploy' executable will always have all of its data obtained
from the 'pkispawn' executable, and will be responsible for exercising
the appropriate 'scriptlets'. Although the 'pkideploy' executable will
remain a part of the 'pki-server' package, since it is not intended to be
a directly executed program, it will therefore be located under
the '/usr/libexec' directory, and will always run with 'root' privilege.
If 'pkispawn' is run on the server, it will gather its information, generate the Admin Certificate Keys and produce a CSR, and send all of this data to the 'pkideploy' executable in order to install and configure a PKI instance. This will be the default case.
Similarly, if 'pkispawn' is run remotely as a client (after the server-side admin has first setup remote access for the client-side admin), it will gather its information, generate Admin Certificate Keys and produce a CSR, prompt for access to the server, and relay this information to the 'pkideploy' executable on the server side. We may want to include something like a "--remote" switch to distinguish whether configuration is on the local host or on a remote host.
In either case, we may simply perform an 'ssh' with the appropriate options to have 'pkispawn' invoke 'pkideploy' with the appropriate data as arguments; it must still be determined what the best approach should be to return the Administrative Certificate.
Note that the Admin Certificate keys will always be generated on the machine which invokes the 'pkispawn' executable.
This also implies that there will no longer be the notion of an installed PKI instance that has not been configured, so the 'pki_skip_installation' and 'pki_skip_configuration' options and their associated code will need to be removed.
This issue was migrated from Pagure Issue #1119. Originally filed by mharmsen (@mharmsen) on 2014-08-22 23:08:08:
To provide a more robust separation of roles, the 'pkispawn' utility should be allowed to be installed on a remote machine such that it may be utilized by a remote administrator to configure a pre-installed PKI instance.
This ticket will require the completion of PKI TRAC Ticket 1118 - Move 'pkispawn' and 'pkidestroy' to a separate package called 'pki-deploy'.
The 'pkispawn' utility should allow configuration of a PKI instance on either a local or a remote machine, but should disallow installation of a PKI instance from a remote machine.
The 'pkidestroy' utility should also disallow removal of a PKI instance from a remote machine.