14:59:42 <sigmavirus> #startmeeting craton
14:59:43 <openstack> Meeting started Mon Jan 16 14:59:42 2017 UTC and is due to finish in 60 minutes.  The chair is sigmavirus. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:59:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:59:47 <openstack> The meeting name has been set to 'craton'
14:59:52 <sigmavirus> #chair sigmavirus sulo jimbaker
14:59:53 <openstack> Current chairs: jimbaker sigmavirus sulo
14:59:59 <sigmavirus> #link https://etherpad.openstack.org/p/craton-meetings
15:00:09 <sigmavirus> #link https://etherpad.openstack.org/p/craton-meetings
15:00:19 <sigmavirus> #topic Roll Call
15:00:22 <sulo> o/
15:00:23 <sigmavirus> o/
15:01:04 <sigmavirus> palendae: jimbaker reminder, we have our meeting
15:02:04 <sigmavirus> sulo: I'll give them a few more minutes but if no one else shows up, want to cancel it?
15:02:14 <sigmavirus> Seems a bit ... hard to have a meeting with just two people
15:02:15 <sulo> ok
15:02:21 <sigmavirus> I mean, we can discuss the agenda
15:02:22 <sigmavirus> :P
15:03:37 <sulo> so was there some discussion on secrets mgt last time ?
15:03:55 <sulo> did we decide to start with barbican ?
15:04:03 <sigmavirus> sulo: well let's go in order :P
15:04:04 <sigmavirus> #topic Action Items from Last Meeting
15:04:08 <sulo> heh ok
15:04:14 <sigmavirus> #link http://eavesdrop.openstack.org/meetings/craton/2017/craton.2017-01-09-14.59.html
15:04:17 <sigmavirus> dangit
15:04:28 <sigmavirus> #link http://eavesdrop.openstack.org/meetings/craton/2017/craton.2017-01-09-14.59.html
15:04:32 <sigmavirus> #info there were no action items last week
15:04:47 <sigmavirus> #topic Storing secrets in Craton
15:05:01 <sigmavirus> So there's been frequent discussion of storing secrets in craton, sulo (to answer your question)
15:05:27 <sigmavirus> There seems to be an unqualified resistance to using Barbican (either by having a soft or hard requirement on it) that I have yet to get any reasoning about
15:05:41 <sigmavirus> Beyond the reasoning that operators don't want to have to deploy things (like Keystone) to deploy Craton
15:06:05 <sulo> right .. but can we do secrets without going that route ?
15:06:27 <palendae> Not against using Barbican; I think I'm past being able to use Craton without Keystone, as everyone else seems to think that's the preferred method
15:06:28 <sigmavirus> sulo: well the design that jimbaker has in mind hasn't made any sense to me personally
15:06:51 <sigmavirus> I think he wants some way of storing the private keys that encrypt the secrets in Craton
15:07:01 <sigmavirus> So that Craton can decrypt the secrets itself
15:07:23 <sigmavirus> I don't think Craton's in the position to do that right now though
15:07:35 <palendae> I'd be -1 to Craton doing secret management itself
15:07:37 <sigmavirus> And I'd rather have the user encrypt the secrets, ship them to craton, and then be in charge of decrypting them
15:07:41 <sigmavirus> palendae: me too
15:08:13 <sigmavirus> That leads me to
15:08:14 <sigmavirus> #info Barbican already provides an HA way of storing secrets
15:08:33 <sigmavirus> Barbican also has a really good access control mechanism for secrets which might not match what we're brewing up for Craton
15:08:49 <sigmavirus> Further
15:08:51 <sigmavirus> #info If Craton absolutely must store its own secrets, it should investigate Castellan
15:09:14 <sigmavirus> Castellan is a project made by the Barbican team for people who need to access secrets storage devices, e.g., TPMs without using Barbican
15:09:27 <sigmavirus> #link http://docs.openstack.org/developer/castellan/
15:09:36 <sigmavirus> #info Topic on mailing list about projects avoiding Barbican, please contribute
15:09:44 <sigmavirus> #link http://lists.openstack.org/pipermail/openstack-dev/2017-January/110192.html
15:09:49 <sigmavirus> #link http://lists.openstack.org/pipermail/openstack-dev/2017-January/110192.html
15:10:01 <sigmavirus> So if y'all have reasons why not to use Barbican in Craton, I'd like y'all to contribute to that thread
15:10:25 <sigmavirus> We should be contributing (at the very least) information back to that project so they know what is holding it back from wider spread adoption
15:10:42 <sigmavirus> I really don't want us to have to come up with ways of storing secrets securely
15:11:03 <sigmavirus> And I really think Barbican has done all of the heavy lifting done w/r/t security and cryptography
15:11:16 <sulo> sigmavirus: is there a bp on secrets mgt ?
15:11:34 <sigmavirus> sulo: jimbaker is the owner so I'm not sure but I haven't seen one
15:11:51 <sulo> ok
15:13:47 <sigmavirus> If we had more of the team here, I'd start a vote about craton storing its own secrets, but there's only 3 of us, so I won't
15:14:03 <palendae> IMO it should be a bp/spec and voting happens there
15:14:04 <sigmavirus> sulo, palendae do you have any topics you want to cover?
15:14:21 <palendae> With explanation of why Barbican doesn't fit and how exactly Craton will manage things differently
15:14:37 <palendae> sigmavirus: Not really; been focused on internal stuff this past week
15:14:55 <jimbaker> o/ - tech problems here, but online now
15:15:01 <sulo> sigmavirus: well, few topics but moslty for my own catchup really
15:15:07 <sulo> like cli work
15:15:32 <sulo> and where we are with the url structure discussion and pagination support
15:15:34 <jimbaker> sulo, in reqs meeting that we had with toan and dusty, we did bring up CLI
15:15:49 <sigmavirus> sulo: pagination spec was merged, and I'm hacking on it
15:15:50 <jimbaker> (as well as pagination)
15:15:52 <sulo> thats where we were before i went on a break
15:16:15 <jimbaker> will read log before my much more commenting :)
15:16:16 <sulo> jimbaker: sigmavirus: ok cool
15:16:49 <jimbaker> sulo, but in a nutshell, toan asked for a demo of inventory against the requirements dusty put together. end of january
15:17:09 <jimbaker> this is not all of the reqs mind you :)
15:17:22 <sulo> jimbaker: ok
15:17:29 <sulo> jimbaker: this is from last meeting ?
15:17:35 <sulo> last week i mean ?
15:17:45 <jimbaker> just doing stuff like getting/setting variables against a host for its hardware/software inventory
15:18:05 <jimbaker> sulo, correct - this is the friday meeting you missed because of leave
15:18:11 <sulo> ok
15:18:57 <sulo> sigmavirus: jimbaker: another topic that was in the middle of discussion was access control
15:19:05 <jimbaker> we need an interface that's not just the python client. so the CLI will satisfy
15:19:22 <jimbaker> sulo, right, i made good progress on rbac
15:19:33 <sulo> jimbaker: nice
15:19:53 <sulo> is there a bp ? we are going with oslo policy ?
15:19:58 <sigmavirus> jimbaker: ah, I never got that invite from dusty
15:20:12 <jimbaker> so in addition to scoped role assignments that's discussed in the rbac blueprint
15:20:15 <sigmavirus> sulo: our rbac seems to becoming quite involved beyond oslo.policy
15:20:35 <jimbaker> as sigmavirus points out, there's stuff beyond just mere oslo.policy
15:21:20 <jimbaker> last week i discussed and showed a gist that lets us connect scoped role assignments to oslo.policy
15:21:50 <sulo> ok .. is there a bp ?
15:22:19 <jimbaker> sulo, it's going in a spec
15:22:34 <sulo> its not merged i guess .. ill check reviews
15:22:42 <sulo> i only see pagination and url specs
15:22:49 <jimbaker> sulo, no, not merged, or even in gerrit
15:22:57 <jimbaker> just still in the writing stage
15:23:00 <sulo> ah gotcha
15:23:19 <jimbaker> but i think it's very much worthwhile to discuss now :)
15:23:34 <jimbaker> anyway, the key to the whole work here is
15:24:09 <jimbaker> 1. scoped role assignments are managed in the database. they are implemented as triples connecting principals (users, workflows) with other mixed in resources on some role
15:24:19 <jimbaker> 2. rest api to actually manage
15:25:02 <jimbaker> 3. usage with oslo.policy as attributed assertions that can then be used as part of standard backwards chaining inference to a given goal as part of the enforce method
15:25:14 <sigmavirus> jimbaker: so the way I see this is that there will be actually two layers of policy
15:25:29 <sigmavirus> oslo.policy and whatever policy enforcement craton does with those scoped assignments
15:26:10 <sigmavirus> The layer of granularity that you're talking about isn't presently done by anyone with oslo.policy
15:26:13 <jimbaker> sigmavirus, it is two level, but more like how it's two level in keystone
15:26:55 <sigmavirus> jimbaker: care to elaborate on what you mean by "it's two level in keystone"?
15:28:04 <jimbaker> sigmavirus, what i mean by that is keystone captures a similar idea in terms of how users and domains are managed in a db; then pulled together using attributes
15:29:14 <jimbaker> anyway, probably best to be discussed in the context of the spec itself
15:32:28 <jimbaker> going through the log: i think there's a difference between managing HSM for master keys themselves; and any encrypted secrets with respect to those master keys
15:33:11 <jimbaker> so castellan/barbican could be good options; so too amazon cloudhsm
15:33:54 <sulo> jimbaker: so just encrypt and store secrets on how to access the real secrets in barbican etc
15:34:20 <jimbaker> then there are tools for managing secrets. so hashicorp vault is a good example here. i don't believe integrations have been done with hsm and hashicorp vault
15:34:38 <sigmavirus> jimbaker: vault would be integrated at the level of barbican
15:34:45 <sigmavirus> barbican is meant to abstract all of that
15:34:51 <sigmavirus> no one has done the work yet though
15:34:52 <jimbaker> the dev work for vault seems to be more focused on rolling secrets
15:35:10 <sigmavirus> jimbaker: like the secrets that sit on top of spaghetti?
15:35:34 <jimbaker> sigmavirus, yeah, and i want to avoid us going down that path if possible. first, implement hsm integration...
15:35:44 <sigmavirus> jimbaker: in craton?
15:35:57 <sigmavirus> Why reimplement what barbican has already painstakingly done?
15:36:00 <jimbaker> sigmavirus, as in a dev path to avoid
15:36:17 <sigmavirus> huh?
15:36:19 <jimbaker> yes, if we re-implement stuff that has been painstakingly done... not a good idea
15:36:39 <jimbaker> sigmavirus, i think we are in agreement here
15:36:57 <jimbaker> at least at a high level. details maybe need to be worked out about our agreement? ;)
15:37:08 <sigmavirus> fair
15:38:28 <jimbaker> related to secrets is, why do we need them anyway? so there are alternatives like trusts
15:38:55 <jimbaker> but apparently the future, while implemented, is not yet widely adopted/distributed
15:39:49 <jimbaker> so we need secrets for the time being. anyway... best discussed i think over a spec
15:39:52 <sigmavirus> jimbaker: I think secrets are deployment secrets and trusts are related to identity
15:40:21 <sigmavirus> so a user can use a trust to authenticate to craton and let it reuse that token with other services taht the users has scoped that too (iiuc)
15:40:34 <sigmavirus> secrets, in the context of an inventory system, are secrets you might use when doing automatic remediation
15:40:49 <sigmavirus> or in the OSA context, passwords that services use when auuthenticating to mariadb
15:40:50 <jimbaker> sigmavirus, trusts and similar tooling like opengrid's myproxy can replace the need for tooling like craton to store secrets to complete the next credentialling hop
15:41:26 <jimbaker> consider for example that myproxy can remove the need to use ssh keys by an intermediary
15:42:08 <sigmavirus> jimbaker: not familiar with myproxy but it seems we're getting a little off into the weeds too
15:42:13 <palendae> jimbaker: Definitely agreed with needing a spec. I'm skeptical that craton needs to add secrets
15:42:29 <jimbaker> all it takes is modified ssh servers. or maybe ssh servers that can talk to kerberos. i don't know. as i said, adoption/distribution means this is not really relevant. eg weeds
15:42:37 <jimbaker> interesting weeds. perspective weeds ;)
15:43:23 <jimbaker> so we still need to manage secrets somewhere. that's the conclusion
15:43:33 <palendae> A deployer does; not craton
15:43:39 <sigmavirus> ^
15:44:09 <sigmavirus> I think we should start with barbican and castellan and let people develop integrations into the services they need
15:44:18 <sigmavirus> we'll have done our dilligence in creating a driver API for that
15:44:32 <sigmavirus> and then people can either hook into barbican or craton or wherever makes most sense to them
15:44:38 <palendae> Or, at the absolute simplest, use TLS and they'll encrypte/decrypt on their end
15:44:44 <sigmavirus> castellan will be for PoC deployments
15:45:07 <sigmavirus> palendae: yeah, I think we'd just keep references to the secret stored in teh driver
15:45:27 <sigmavirus> I don't think we should handle the secret at all if at all possible
15:45:55 <palendae> sigmavirus: Well, I'm talking about the scenario of storing an encrypted secret without a 3rd service. But, for me, that's preferable to Craton adding yet more stuff
15:45:59 <sulo> sigmavirus: jimbaker: i thought that was always the plan ? driver support for one or two backends by default ..
15:46:16 <sulo> so all we have to do is be able to handle .. where the secret is and how to get it
15:46:18 <sigmavirus> sulo: I don't know if that was always teh plan
15:46:28 <sigmavirus> sulo: right
15:46:41 <sigmavirus> we have 12 min left
15:46:44 <sigmavirus> do we have other topics?
15:46:45 <jimbaker> sulo, yes, for master keys. whether for secrets as a whole like ssh access keys, clearly we didn't go there
15:47:48 <sulo> i dont have anything .. ihave a few things to catchup on
15:48:24 <jimbaker> sulo, we should just sync up with the reqs meeting
15:48:51 <sulo> jimbaker: ok
15:49:03 <jimbaker> so no changes there on that doc that dusty is putting together
15:49:13 <sulo> jimbaker: sigmavirus: i think we have things on our priority list
15:49:14 <jimbaker> which should be published soon
15:49:29 <sulo> but maybe its worth putting down the workitems and goals for this cycle etc
15:49:31 <jimbaker> sulo, i assume by this you mean
15:50:03 <jimbaker> sulo, i assume by this you mean current inventory model stability/production scale
15:50:06 <jimbaker> plus CLI
15:50:07 <sulo> jimbaker: i mean, access control, secrets mgt, workflow and cli work
15:50:11 <sulo> jimbaker: yes
15:50:21 <sulo> pretty much
15:50:46 <jimbaker> sulo, yes, we can do that in parallel for access, secrets, auditing, and remote inventory integration ("inventory fabric")
15:51:12 <jimbaker> sulo, with these last aspects, we have a comprehensive inventory system
15:51:35 <jimbaker> the other piece is workflows, but that can be on the back burner
15:52:03 <jimbaker> inventory seems to be far more important to get complete first
15:52:08 * sigmavirus thinks auditing is higher prio than secrets
15:52:27 <jimbaker> sigmavirus, likely is
15:52:40 <sulo> right .. i think inventory is taknig shape .. for next phase of work though
15:52:41 <jimbaker> secrets are for sure harder to get right
15:52:43 <sulo> like auditing
15:52:50 <sulo> we need secrets and access control
15:53:03 <sulo> to we can hit machines
15:53:12 <jimbaker> exactly, it all works together
15:53:39 <jimbaker> and i think secrets is harder with respect to daemon usage
15:53:43 <sigmavirus> sulo: last time I was in a meeting with Rackspace's support team, automated remediation is a very low prio item given they don't want Craton doing things for them
15:53:46 <jimbaker> like workflows
15:54:18 <sulo> sigmavirus: ok .. yeah i guess we are kinda far from that also
15:54:53 <jimbaker> hence my "back burner" prioritization
15:54:55 <sulo> but auditing is the same process as remediation
15:55:01 <jimbaker> yeah
15:55:05 <sulo> the inner working is the same
15:55:05 <jimbaker> and they will want it
15:55:18 <jimbaker> otherwise we lose the efficiency gains we want to see here
15:55:25 <jimbaker> and agreed about effectively the same
15:56:00 <jimbaker> sulo, so nothing is changed as we look at 2017
15:56:05 <jimbaker> (and btw, welcome back!)
15:56:13 <sulo> thanks :)
15:56:14 <jimbaker> inventory first, get that deep
15:56:26 <jimbaker> and build out workflows around it
15:56:33 <jimbaker> jason's original priorities for us
15:57:01 <jimbaker> we are just hearing it from toan and dusty as well
15:57:09 <sigmavirus> Anyway, let's continue in #craton so we don't step on the next meeting's time
15:57:15 <jimbaker> sigmavirus, agreed
15:57:29 <sigmavirus> In the future, I think I'll run meetings and force us to stick to the posted agenda
15:57:34 <sigmavirus> Because I can
15:57:36 <sigmavirus> #endmeeting