Issue #2013
closed
SSL certs are created at install time, but should be at setup runtime
Description
The report from Red Hatter Kurt Seifried is quoted below from the corresponding BZ and describes the issue well. We should probably have pulp-manage-db create the certs if they are missing. (And for that matter, we should probably rename it at some point to pulp-setup or something like that.)
Kurt pointed out this resource, which is a valuable guide on the general topic: https://fedoraproject.org/wiki/Packaging:Initial_Service_Setup
Version-Release number of selected component (if applicable):
pulp-2.4.1-0.7.beta.el7sat but latest upstream also has it.
How reproducible:
Always.
postinstal:
openssl genrsa -out $KEY_PATH 2048 &> /dev/null
openssl rsa -in $KEY_PATH -pubout > $KEY_PATH_PUB 2> /dev/null
Steps to Reproduce:
1. Install to a container or image.
2. Run new instance of container or image.
3.
Actual results:
All container and image instances share the same key/cert.
Expected results:
Each instance should receive a unique key/cert.
Additional info:
This bug is being file because Product Security considers "first run problems" to be bugs with the source package and with the container or image only in the aggregate. This view is in collaboration with upstream Fedora. See: https://fedorahosted.org/fpc/ticket/506
The recommended resolution for services is to follow the "First-time Service Setup" pattern (see: https://fedoraproject.org/wiki/Packaging:Initial_Service_Setup ). Other packages may should use a runtime check and generation or similar procedure.
Updated by amacdona@redhat.com over 8 years ago
- Priority changed from Normal to High
- Severity changed from 2. Medium to 3. High
- Triaged changed from No to Yes
Updated by jcline@redhat.com over 8 years ago
Note that this probably applies to several subpackages and needs to be fixed in our spec files as well as Fedora's spec files after the keys are generated as part of the first-time setup.
Updated by jortel@redhat.com about 8 years ago
- Status changed from NEW to ASSIGNED
- Assignee set to jortel@redhat.com
Updated by jortel@redhat.com about 8 years ago
As suggested, I considered the initial-service-setup [1] recommendation but the generated key pair and certificates are required by the pulp code running in httpd. So, there is no pulp service (systemd unit or upstart script) that can be used to hook this into service startup.
The proposal:¶
1. Move the RSA key pair generation script code out of pulp.spec into a new script named: pulp-gen-key-pair.
2. Remove call to pulp-gen-ca-certificate from pulp.spec.
3. Add new script named: pulp-setup that calls:
- pulp-gen-key-pair
- pulp-gen-ca-certificate
- pulp-mange-db
and update installation documentation to run pulp-setup instead of pulp-manage-db.
4. Leave upgrade documentation referencing pulp-manage-db unchanged.
5. Ensure both pulp-gen-key-pair and pulp-gen-ca-certificate scripts are idempotent. When the generated files exist, they print an appropriate message and exit.
6. Ignore the pulp-gen-nodes-certificate that is called when nodes is installed by the RPM since Sat 6.2 no longer uses nodes and it has been deprecated upstream.
Questions:
1. Thinking of clustered pulp installations - is calling pulp-manage-db by pulp-setup still appropriate?
2. Better ideas?
[1] https://fedoraproject.org/wiki/Packaging:Initial_Service_Setup
Updated by bmbouter about 8 years ago
I really like this write up, thanks @jortel.
I like the idea of pulp-setup, but if all it does is call those 3 scripts I think having the user just call them one after another manually will be fine. My thinking is that it's not doing much at all and the user will get some understanding about pulp-manage-db that will be useful to them at upgrade time. -0 to keeping pulp-set.
Even though nodes is deprecated, I don't think we can knowingly break it until it is removed. To handle that aspect, consider adding documentation to the nodes setup indicating when and where they should call pulp-gen-nodes-certificate. That would be straightforward to do I think.
+1 to pulp-gen-key-pair and pulp-gen-ca-certificate scripts be idempotent and when the generated files exist, they print an appropriate message and exit.
For a clustered install which of these 3 scripts (pulp-gen-key-pair, pulp-gen-ca-certificate, pulp-mange-db) needs to run on all nodes, and which needs to run exactly once?
Updated by bmbouter about 8 years ago
Also, we should consider having someone from product security review this PR
Updated by jortel@redhat.com about 8 years ago
Thanks for the comments, bmbouter.
bmbouter wrote:
Even though nodes is deprecated, I don't think we can knowingly break it until it is removed. To handle that aspect, consider adding documentation to the nodes setup indicating when and where they should call pulp-gen-nodes-certificate. That would be straightforward to do I think.
Agreed. Good suggestion.
I was not planning to break nodes .. just ignore it (and the problem) by leaving the pulp-gen-node-cert in the pulp.spec. But, I like your idea better :)
For a clustered install which of these 3 scripts (pulp-gen-key-pair, pulp-gen-ca-certificate, pulp-mange-db) needs to run on all nodes, and which needs to run exactly once?
It's my understanding that pulp-manage-db would only be run once for the cluster and pulp-gen-key-pair and pulp-gen-ca-certificate would be run on each node. Is this correct?
Updated by jortel@redhat.com about 8 years ago
- Status changed from ASSIGNED to POST
Updated by dkliban@redhat.com almost 8 years ago
- Sprint/Milestone changed from 31 to 32
Added by jortel@redhat.com almost 8 years ago
Added by jortel@redhat.com almost 8 years ago
Revision 7476b6cb | View on GitHub
RSA key pair and SSL CA certificate generation removed from pulp.spec. closes #2013
Updated by jortel@redhat.com almost 8 years ago
- Status changed from POST to MODIFIED
Applied in changeset pulp|7476b6cb6971ff5a513152b698fb7b861dcc42a0.
Updated by pcreech over 7 years ago
- Status changed from 5 to CLOSED - CURRENTRELEASE
.
RSA key pair and SSL CA certificate generation removed from pulp.spec. closes #2013