14:00:47 #startmeeting Pulp Triage 2019-12-05 'Content Signing' 14:00:47 !start 'Content Signing' 14:00:47 #info dkliban has joined triage 14:00:47 Meeting started Thu Dec 5 14:00:47 2019 UTC. The chair is dkliban. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:47 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:00:47 The meeting name has been set to 'pulp_triage_2019-12-05_'content_signing'' 14:00:47 dkliban: dkliban has joined triage 14:00:55 #info misa has joined triage 14:00:55 !here 14:00:55 misa: misa has joined triage 14:01:00 https://docs.google.com/document/d/1HSrRduFYuidhbc8ISjUnkb3IXk6FnJ2iXEqa4vDC-pA/edit?usp=sharing 14:01:16 ^ there are the use cases we discussed so far and the notes from the last meeting 14:01:31 #info ggainey has joined triage 14:01:31 !here 14:01:31 ggainey: ggainey has joined triage 14:03:04 This is what we're using for signing stuff: https://github.com/sassoftware/relic 14:04:09 * dkliban reads 14:05:01 misa: so in this case you have an external service that does all the signing 14:05:03 client/server signing infrastructure. The server can talk to an HSM (hardware security module) 14:06:00 dkliban: yep. Conceptually similar to gpg itself in the end. However, unlike gpg (or most gpg implementations), you have no access to the private key material 14:06:33 setting up one of these belongs to the Administrator role 14:07:18 #info daviddavis has joined triage 14:07:18 !here 14:07:18 daviddavis: daviddavis has joined triage 14:08:10 daviddavis: ttereshc: we are discussing https://github.com/sassoftware/relic .... that's a service that signs packages 14:08:34 one of the use cases that we discussed last time was using something like ^ to perform the signing 14:08:35 To resume the discussion: maybe what you want are high-grade/production and low grade/dev/testing scenarios 14:08:50 #info bmbouter has joined triage 14:08:50 !here 14:08:50 bmbouter: bmbouter has joined triage 14:09:11 #info ttereshc has joined triage 14:09:11 !here 14:09:11 ttereshc: ttereshc has joined triage 14:09:12 To resume the discussion: maybe what you want are high-grade/production and low grade/dev/testing scenarios 14:09:30 (should we wait for a few more minutes?) 14:10:00 no, I think we're good 14:10:24 yeah ... let's continue 14:11:19 misa: we want to support use cases where the signing is done externally and signing is performed by Pulp 14:11:45 and perhaps that's what you mean by high-grade (external) and low-grade (internal to pulp) 14:11:46 As we learned from docker (v2 schema 1 manifests are signed), a signature with a random key is not much better than a checksum 14:12:14 the value of signing is in the trust of the key 14:13:10 so as a consumer of whatever, I need to be able to tell with a certain amount of certainty that: 1) I trust signatures by this key; 2) the infrastructure hosting this key is reasonably secure 14:14:17 we discussed last time that we there is desire to have Pulp hostingthe private key 14:14:18 a user uploading their key and then signing packages is ok for testing, but inherently low-grade 14:15:01 misa: what about an administrator putting the key in place and then signing with it? 14:15:58 definitely higher grade, yes, in as much as it comes to securing the private key 14:17:07 bmbouter: you were interested in the use case wehre the REST API user uploads a private key that will be used for signing 14:17:40 RBAC plays a role in this whole thing. Let's take the use case of RHEL. If any developer can upload a package and have it signed with the RHEL8 signing key (trusted by millions of users), it doesn't matter that the key lives in an HSM, the process up to the HSM is flawed since it imparts trust to packages that are not verified 14:18:44 yes I was thinking more about that use case 14:19:14 but I think that's a different discussion. I was only offering that to describe why it's hard to categorize high grade/low grade because it's not just about key storage. Anyway. 14:19:15 and also misa's proposal, the main aspect about misa's proposal is that private key provider/configurer is the deployer of pulp 14:19:45 so I was thinking that misa's use case is probably the best starting point for 3.1 14:20:14 If we come up with the concept of a signing service, and allow more than one signing service to be configured (by an Administrator), then we need to define the interface to a signing service 14:20:19 but i just heard a concern about everyone being able to sign packages with the same key 14:21:10 a signing service could be as simple as a bash script that is being fed a number of environment variables, filled in by the plugin, and that invokes gpg in its easiest form 14:21:18 misa: so the signing service probably needs to b only available if the user has the permissions to use it 14:21:27 right 14:21:30 agreed 14:21:33 RBAC will help w/ this 14:21:38 as I think I read ^ also 14:21:44 yes 14:21:49 +1 to that 14:22:15 for the RBAC to layer onto these objects they need to be in the db 14:22:35 yes, there needs to be a DB record that represetns the signing service 14:22:40 at least a representation of how to connect to it, I'm not suggesting the keys themselves 14:22:44 +1 14:23:23 Here's a proposal: administrator is the only one that can add services, using a command line tool 14:23:52 pulp_ansible can use this approach at least for the near-term 14:23:55 the tool has commands like add, remove, grant (for RBAC) 14:24:30 it validates that the command line for signing does exist, and pushes a record in the DB 14:24:41 can we leave the RBAC mechanisms a bit abstract because we want it to be consistent w/ the other RBAC assignments 14:24:52 so command line tool would add/remove signing services 14:25:15 As an administrator, I can use django-admin to add a signing service to Pulp. 14:25:24 add/remove +1 14:25:29 yes, both 14:25:32 ja 14:25:39 sounds good 14:25:40 да 14:25:47 kekeke 14:26:09 should we discuss how the signing service should be described? 14:26:23 yes, misa does your proposal outline aspects we can use? 14:26:34 it could :-) 14:26:44 if not then let's spitball here 14:26:54 let's finish the personas 14:26:58 sure 14:27:10 repository administrator configures signing service for the repo they created 14:27:25 RBAC may deny them from adding a service 14:27:29 +1 14:28:00 pulp may (not day 0) provide a plugin for managing keys remotely 14:28:12 +1, repository administrator being the end-user, someone who has the RBAC permissions to both that repo and that signing service 14:28:52 administrator may configure a signing service that uses the private keys managed by the hypothetical pulp plugin 14:29:17 so the plugin and its service are completely optional 14:29:27 yup over time that would be cool yes 14:29:34 bmbouter: I don't understand the ansible use case, will this cover it? 14:32:47 misa: it will cover it for the near term 14:33:19 it's an acceptable downside, but this issue is this doesn't scale to a large number of users/keys 14:33:34 but that's not unique to pulp_ansible 14:33:51 and not something we need to focus on resolving in the nearterm (the more I thought about it) 14:34:07 for 3.1 we can focus on providing a single Signing Service type 14:34:20 it would be similar to what is in pulp_deb now. 14:34:34 +1 14:34:39 cool. 14:34:55 +1 14:34:59 In terms of what a signing service does: 14:35:36 In our case, we have one service configured with multiple signing keys. The wrapper bash script around relic determines which key to use based on the repository name 14:36:17 because we have a dev/test/prod scenario, and we don't want dev repos' metadata to be signed with the prod key, for instance 14:37:12 This is the reason https://github.com/pulp/pulp_deb/blob/2-master/README.md#signing-support documents that GPG_REPOSITORY_NAME will be filled in by pulp_deb and passed to the signing service 14:37:30 The plugin writer may add extra variables, of course 14:38:01 So I think there are, once again, multiple layers/flavors/use cases for this. 14:38:05 I expect the application code would be enforcing the repo<->key relationship 14:38:42 1. administrator configures signing service to use exactly one key (even though there are multiple keys in the store) 14:39:25 2. administrator leaves the key blank, and lets the signing service pick a key based on a number of environment variables (like repository name, for instance) 14:39:54 3. administrator leaves the key blank and also allows for the user to specify the key to be used for signing 14:41:06 4. repository administrator defines the key to be used for their repo 14:41:33 5. repository administrator defines a list of keys that can be used, that a content producer can specify for signing their packages 14:41:38 for pulp_ansible's purposes we want the admin configuring the signing service/keys 14:41:52 yes that sounds like (5) 14:42:27 so there's like service-level config, repo-level config, content producer config 14:42:40 I'm not understanding 14:43:00 my last statement? 14:43:49 are we listing options, or are you saying all of these should be done? 14:43:57 What i think he meant was that the Administrator configured a Signing Service. When the repo admins adds that service to a repository, he also provides configuration. 14:44:12 right. 14:44:40 I don't think I have a clear idea of a repo admin persona 14:45:08 repo admin is someone that creates the repository and assigns it a specific signing service 14:45:19 it may or may not be the same person as the Administrator 14:45:54 repo admin also possibly limits the signing keys the signing service has 14:46:18 I think that's part of the confusion to me, in the case the "repo admin" and the "Administrator" are not the same how can the repo admin provide additoinal configs tothe box they can't access 14:46:38 having the Admin define all the things and have RBAC limit who can use them did make sense to me 14:46:38 bmbouter: think whitelists 14:46:51 bmbouter: admin says service has keys A, B, C 14:47:12 sounds good 14:47:16 bmbouter: repo admin says content producer can only use B, C, D 14:47:25 who is content producer? 14:47:27 D is invalid because the admin didn't specify it 14:47:34 bmbouter: person uploading artifact, for instance 14:47:43 k sounds good 14:48:00 then content producer may pick between B and C 14:48:20 ok I'm understanding 14:48:36 but aren't B, C, and D "references" to objects the admin configured 14:48:45 so how is the repo admin specifying a reference to something that doesn't exist? 14:49:05 bmbouter: don't know :-) 14:49:09 bmbouter: for the most basic signing service these are just strings 14:49:18 bmbouter: I was assuming they were GPG key fingerprints, for instance 14:49:22 one may mistype one 14:49:46 ok thinking of them as fingerprints makes it more clear 14:49:46 or maybe A, B, C, D were initially configured, but the admin retired D. 14:50:08 but repo admin didn't update the config, so what was once a valid ref to D is no longer valid 14:50:18 ok this sounds good 14:50:35 admins configure keys/signing and users reference them w/ fingerprints 14:50:42 right 14:50:50 sweet 14:51:09 why have more than 1 signing key per repo? 14:51:12 to summarize that case for a (admin, repo admin, content producer): ([A, B, C], [B, C], [B]) 14:51:38 bmbouter: donno. I suspect one may want that 14:52:28 i am having a hard time picturing that scenario also 14:52:32 pulp-gpg case could be that the admin allows any available keys, but the repo admin limits to a number of them, etc. 14:53:05 but i do want to summarize the use cases we went over so far today ... 14:53:13 yup 14:53:28 As an administrator, I can use django-admin to add/remove a Signing Service. 14:54:15 As a REST API user (repo admin), I can assing a Signing Service to a repository and provide a key signature as additional configuration. 14:54:59 As a REST API user uploading content into a repository, I can specify a key signature of the key to use when signing the uploaded content. 14:55:15 Sounds good 14:55:27 it's a good recap 14:55:31 I'm not sold on the last one 14:55:45 bmbouter: I think the use case would be something like rawhide 14:55:45 but for our time today it's great content/discussion 14:56:10 developer uploads package, signs it with his own key 14:56:43 I can't think why this is useful 14:56:54 i will add these to the document along with a summary of today's discussion 14:56:58 but I think for a while that's how it was working, before there was a centralized build system 14:57:06 yeah we can include it for now anyway 14:57:17 I don't want content providers to have to think about keys for pulp_ansible 14:57:28 bmbouter: i think it's optional 14:57:49 The discussion about ABC -> BC -> B was only to describe that admins may restrict key selection 14:57:52 bmbouter: repo admin can set a single key to use 14:58:08 pulp_ansible will be set then 14:58:21 but I don't understand how it's useful generally 14:58:31 that's ok though I'll think about it 14:58:57 dkliban: in the hypothetical case of rawhide/dev keys, that's when you may want to have more than one key configured by repo admin 14:59:41 misa: yes, and the key might be selected based on the user that is uploading the content 14:59:53 yeah, something like that 15:00:05 alright ... i am going to end the meeting now 15:00:12 i'll schedule another discussion for next week 15:00:20 ty! 15:00:26 #endmeeting 15:00:26 !end