 Thank you. Hello, everyone. I'm Dustin Collins Today I'm talking about summons. So this is an open source tool I created to make it easier to work with secrets and source control by day I am the developer advocate at conjure and by night. I organized the Boston DevOps meetup So I want to talk about a few patterns and source control before I get into summon So we have secrets in source control So I like to think of secrets as dependencies so it makes sense to have them in source control But the problem with this is that you have really weak access control on the dependencies people who have access to the repo And I've accessed all your secrets The second pattern is secrets not in source control. So you remove them and you put them somewhere else Let's say for example, you lay down secrets with your config management in your application Expects it to be there. So that's okay But then you have these implicit dependencies secrets encrypted in source control I see this is kind of just kicking the problem down the line because now you've created decryption keys Which are also secrets not so great I think a better pattern is secrets referenced by source control. So You you put the paths where secrets can be retrieved in source control and then you put that next your applications You can track changes and Then summon really works with this so summon is a command line tool that Resolves reference secrets as environment variables into any process So there's a few different parts of summon, which I'll go into now the first part as It goes is a secret set YAML files. So this is a mapping of environment variables to Pass where secrets are stored and you can see here. We have some Vars, which means this is a secret. We have some literals and then we have files which resolve to memory mapped Pass to memory mapped files An important part about summon is that it has pluggable providers So you're not locked into any any certain Secret store so if you want to use vault you can use the vault provider if you want to use conjure you can use a conjure provider The contract is really simple. It's easy to write providers The providers available already are conjure AWS s3 OS X Linux key ring and chef data bags Some ideas I have but I'm a little short on time. Hyra has she called vault keywords Or you know, you might have your own internal system, right? You can write it for that I wrote summon and go so it's just a single binary. You can stick on your systems. You don't have to worry about dependencies It's got a bunch of flags, but there's defaults for many things. So usually you can just say summon your tool and you're off to the races And then the last part is the process. So I mean a tool, right? So you want to run Terraform or Docker or something like that So any tool that accepts environment variables can be used with summon and so now I'll show some examples of how I use summon day-to-day I use it with Docker so you can see here. There's this magic at summon and file So if you put that when you call summon it creates a memory mapped file that resolves your secrets and the end file format It makes it available to Docker. It's really useful I use it with chef because I really hate working with the data bags API So I just summon my secrets in there and then I can use Ruby env Just grab the secrets that way I use a test kitchen to test some my infrastructure code. So that's it's a similar pattern here. You can see I'm using the var file in the secrets.yaml So this resolves the private key into a memory map file and then the value of that environment variable is the path to that file I discovered this just a couple weeks ago that I can also use with Postgres So this is really nice because I can just summon put the Postgres password drop into the psq all prompt Mess around and then when I exit the passwords not left on my system. I use it with Terraform There's a little trickery here because you have to use TFR for environment variables So it resolves the Terraform variables works pretty well And I use about the ansible so you can use it with ansible for secrets But I use it for the private key that I use SSH around machines because I don't really want to leave that on my machine And then you can interpolate the users so you can use different users without to switch your secrets.yaml file An important thing to know about summon is that it does not solve authentication and authorization Why am I allowed to access these secrets? This is on the provider So for example for the s3 provider you might want to use IAM roles something like that How can you contribute you could just use summon and let me know what you think about it You could write a new provider. It's very simple. You could even write one in bash Or you can open for requests on summons core. All of this is open source Thank you Get summons on github. You can talk about on Twitter with hashtag summon I write stuff at dustinarcolons.com and my Twitter handle is dusted on mm80. Thank you