Best Practices for Using HashiCorp Terraform with HashiCorp Vault

hello everyone first thank you for joining us this morning today we have a secret REO and software engineer Becker Petra in here she's going to demonstrate how the best practices for using Asha curve turn form with Walt and and demo some of the features and can utilize with the two we will then spend the last 15 minutes of the webinar dedicated to Q&A I do want to reiterate that this webinar is recorded and will be available to you post-processing usually within a day or two so look out in your inbox in the meantime there is a questions box feel free to put your questions in there and we'll get to them at the end of the webinar with that we'll get started and off to you Becca cool thank you all right my screen shown um let's see here okay all right there we go okay so hi my name is Becca Petra and I'm a software engineer on the vault team I've been with Walt since February of last year and I am also the engineer who maintains the terraform vault provider which is letting me to do a lot of thinking about how terraform and vault work together what are they both good at where does the responsibility of one start and the other end because of that today we're going to cover best practices on how to use vault and terraform together we'll cover how to use terraform to spin up a real vault cluster backed by console and running in AWS and how to do this in only five minutes and then we'll configure vault and use vault to feed further secrets into terraform so being a vault engineer my main focus is security on the vault team we passionately believe in the importance of protecting sensitive and secret data and so today we're going to show you how I hope that by the end of the presentation if you are new to these tools you can take away a couple of tips on how to get going with them and if you're not new to these tools I hope that you can take away some tips on how to do what you're already doing but more securely so the sections that we're going to go through today are these in getting started using terraform we'll start by spinning up our cluster using this pre created Terra firme config that is available to you in recommended architecture we'll take a look at the the actual architecture will be spinning up and how it works and the CD in vault with threats we're going to cover not only how to get secrets and sensitive data into vault but how to protect those secrets against loss and finally in consuming those secrets we'll cover how to use terraform for further infrastructure on your team I chose an AWS for this presentation mainly because I'm most familiar with it but all of these actions can be taken on any platform including TCP a juror or Olli cloud and also I'm going to kind of use some tools here and there and at the very end I'm going to show a slide that has the links to all of the references that I'm using so you can copy what I'm doing at your workplace um but before I start we're gonna have people at many different levels here and so some folks who are more familiar there will be some folks more familiar with one thing than another so I wanted to give like a quick vocabulary drive by terraform is a cross-platform tool for writing infrastructures code which will be using the create resources really quickly vaults is a cross-platform Swiss Army knife for protecting against data leaks console as vault uses it is a database for storing secrets in an encrypted format but it's also a wonderful service mesh tool and finally AWS is short for Amazon Web Services will be spinning up our cluster today on Amazon ec2 instances everything that we do today is going to be using the open source or free version of all of these Hashi core applications but once we spin up our vault cluster using AWS running these applications on AWS does incur a cost and it would on any Google cloud or any platform and so we thought we'll of that as you follow along when you actually run the terraform apply commands that is when you would be spinning of real resources that cost real okay so getting started using terraform so in just a moment I'm gonna begin spinning up our recommended architecture I'm gonna let it run over the course of five minutes while I'm telling you about it and then we'll circle back to it and we'll continue setting it up what I'm going to do on the batch command line here is I've actually already run this AWS configure command before our presentation what it did is it allows me to add AWS an AWS access key and secret to my shell environment and the ones that I configure here they're going to be used by terraform to spin up those real AWS ec2 instances I mentioned earlier then when I run get clone in a moment I'm gonna pull down some pre-made get code from github and this is from a public repository that you can access and then I'm going to change my directory into the best practices architecture section and I'll run terraform there is one change that I'm gonna make before I run this code I'm going to change it to use the AWS s3 remote state back-end so what is that well whenever Terra firme runs it spits out this file that records all the things that it created so that the next time it runs it knows what's already out there and what it needs to change and so that file is called the terraform state file the terraform state file often includes sensitive data and by default this file is added to your own laptops for you to see so for to prevent that file from becoming a possible attack vector instead of putting it on my own laptop we're actually going to protect it by instead of telling terraform to put that file into an encrypted s3 bucket so I'm gonna add it to my terraform config before I run it I would recommend using steep file encryption for terraform anytime there's a lotta left secret in your terraform config or state in this case the AWS key that I'm going to be using it's going to live for a good amount of time so that is why I'm using state file encryption in this case AWS does recommend that these these keys and secrets are rotated periodically as well and we do agree with that recommendation so I'm gonna go ahead and get this started we're going to come on over to the terminal all right just getting my terminal up here all right great so you should be able to see that now okay so let's go through those commands that I just talked about so I am gonna go ahead and pull down that pre-made code that I wanted and I'm going to change into the directory where the code lives that I'm going to use I'm gonna list the things in here so you can see what's here so what we have are some terraform config files that have been pre-made for you by the team here at Hoshi poor and these are for spitting up a best practices cluster on AWS now I'm going to actually edit that main TF file to use the remote state backends that I talked about so I'm gonna add it right here to the top and I'm gonna save it and then I'm gonna run perform and it tear for a minute obviously initializes terraform what it's doing right now is looking inside all of the config files that were here in the directory that I showed you and saying oh what code do I am I going to need in order to run this and it's pulling down all of these different plug-ins for terraform that will spit up and their vault and console for you and in the AWS environment so now that's done and the last thing I'm going to do is run terraformed apply and this is where it's pulling my Amazon config my key and secret it's asking me of course what region I want to be spinning up resources in and I'm going to use US East one which is very common region to use because it's the one that we're a WS rolls out most of its features first and then it's seen so what it did right there is it looked at Amazon in region US East one to see if I already hiding these resources that I'm asking for it to create and it's not that I don't so it's planning to add 127 things and it doesn't have any that change or destroy and it's asking me if I really want to do this now if you type yes here this is the part where it spins up real resources that cost you money so do this slap Foley I'm gonna go ahead and hit yes and tear form is going to get to work I'm spinning up all those resources meanwhile while it's doing this so that we're not just watching a whole bunch of texts whirring across the street screen I'm gonna go over it and I'm gonna tell you about a little bit about what terraform is doing so let's go back over to the presentation let me get it up again here here we go all right so recommended architecture what is terraformed doing right now it's spinning up a single data center for vault the cluster that we're going to be looking at today is seven total instances three of them are vault servers through your console servers and they're protected by Bastion host in front of them and thus they aren't directly exposed to the internet a bastion host is a special-purpose computer on a network specifically designed and configured to withstand attacks the computer generally hosts a single application for example a proxy server and all other services are removed or limited to reduce the threat to the computer vault is further Reddit ready to withstand attacks it encrypts all secrets in transit and at rest so if someone were to try to look up vault secrets directly and console they'd only see the encrypted version of the secrets not the secrets themselves so please note that once these instances are up we do recommend that you also watch for a production hardening guide it will take you through further steps to complete once they're set up such as trimming off core dumps enabling auditing and disabling the shell command history we're not going to do that today though both in the interest of time and because the production heard her main gain is it's very straightforward to follow and so there's not a huge benefit for you know to have me walk you through it today now once these instances are up how will they fit in to how we're going to use terraform and vault together so in the Hashi course stack vault is absolutely the only place where your secrets and sensitive data should be managed when members of your team are using terraform to spin up additional resources we recommend that you have them authenticates of vaults using an easy off method like github get a vault token specific to them and then run terraform with their individual vault token pulling all the secrets they need directly from vaults will give a specific example of that later but I just wanted to start introducing you to this idea but basically one you can use terraform to spin up your ball cluster that's what we're doing right now to a highly privileged person should place secrets into vault and configure access to them we're going to do that in just a moment and then three people on your team using terraform should use it with their individual vault token and with no secrets placed directly in the config and we're going to look at that workflow in a moment as well it's pretty simple workflow it's actually pretty cool so um this might give rise to a question um if secrets aren't in the terraform config then how are the secrets in vault backed up well we recommend using consoles snapshotting mechanism to save and restore the encrypted vault data that has been placed in it this will allow you to save and restore vault secrets while continuing to keep them in a safe and encrypted format that way although they're backed up and they're recoverable they're also still not in plain text anywhere so it's very secure it's grenades alright so now architecture we've been discussing and should have finished spinning up let's go and take a peek inside our AWS console and see what is there all right we're going to get out of this presentation for a minute go right over to AWS and let me go ahead and refresh this there we go that looks about right okay so right here you can see that we've got seven instances there are some other instances that are unrelated to what we're doing today because we use this account for testing but basically we've got our best practices architecture up now we've got seven instances that we've got a bastion host three console nodes and three vault nodes a couple other things to notice about this are that the instance type is a t2 small that we're using I'd like to clarify about this that this is not our recommendation this is these are just some really small instances to keep the cost down for it when you're initially playing with our best practices like cluster we actually recommend m5 larges as the instances that you would use in a real production environment so you would just edit the terraform config to have that we we do have a recommend like a architecture recommendation website where you can like read through all of the recommendations for like the instance sizes and then decide what best suits your own organization I'm going to link it at the end but you would want to change that before actually spinning up this architecture another thing you might notice is that we don't have everything in the exact same availability zone we did that on purpose um the reason is that if one physical data center goes down we want to be able to have redundancy and so that's why we've got things in 1a 1b and 1c over here in the availability zones so okay let's go ahead and see what's here form we're terraform is that right now let's return to our terminal let me get you to the terminal here alright here we go alright so we're back to the terminal where we were running our form it's finished up and stopped which is awesome um so I'm gonna go ahead and continue getting this set up so when you actually spin up a vault instance it comes up in a sealed state by default that means that it's not serving any web traffic the reason that we do that is because we want to make sure that nobody is spinning up an instance out of bands at your company that you don't know about and so whenever an instance comes up it has to be unsealed with these particular keys the first time that UNC late you're giving these keys and then API something to get started and so we're gonna go through that process right now and I'm doing this all live so that you can follow along so the first thing we need to do we we get these instructions on how to interact with our new vault cluster right here so it's created some SSH keys for us to use the first thing I'm going to do is go ahead and add the SSH key to my keychain here on my Mac and then the next thing I'm going to do is I'm going to use that SSH key to actually head into my my Bastion so here I am copying right onto the Bastion here so I really want to connect yes and so you can see from my command line that I am now on the bastion host that's why I've got this little this little intro here and so now that I'm on the bastion host I have access to getting into my vault servers where I'm gonna go to initialize vault so I do have another command here that will get me right onto those it's this gonna copy that and paste it and this is asking me if I really wanna go yes I do ok so you can see here I'm no longer on the bastion I'm now in a vault node and so what I'm going to do to start off is run volt operator and it this is going to give me my first time unseal keys and my initial root token in real life you would distribute these to three people and then you would do your initial setup and revoke the root token I'm not going to go through all of that today because that's not the main focus of this particular presentation but I am going to record these unsealed keys here and then I am going to use them actually unsealed vaults on this node so that would be vault operator and seal so I'm going to do this with three different keys here and finally the third one okay so now we can see right here that it's not sealed anymore so that's one of our three vault modes we're going to do this with two other um please bear with me this will take about three minutes max I would guess to unseal these other two nodes and then we'll get back to the more exciting part of our presentation but the reason I'm doing this live is because I really wanted you to see exactly how you would do it so that if you are following along on your own that you don't have any points where you make it stuck basically so um I dropped back down to the bastion host by hitting ctrl D now I'm going to go into the second vault server by going like this it's gonna ask me if I want to do this and I'm gonna do a vault operator and scale here as well with three different keys which I've recorded over here okay and then they get that last one all right so now we see that this is no longer sealed and we've got one more node to do this on and then things will get more interesting again all right last one okay that's one two and the last one okay okay that's it we literally have a vault cluster up in serving traffic now I'm gonna hit control D again to drop right back into my bastion host and the last thing I'm gonna do to get ready to start setting a fault further is I'm going to add a vault token here the vault token that was given to us earlier so I'm going to do export token is equal to this and there we are okay great um so let me get back over to our slideshow just a moment and I will get continue talking about all of this and what we're doing and why we're doing it okay see here okay thanks for sticking with me there okay I almost got this showing there we are alright so now we're going to get into seeding vault with secrets but before I do I want to kind of give you a high-level overview of what I'm doing and why I'm doing it because that's really the more important piece of the contexts to take away here so basically the way that the way that we're going to be setting this up is let's say I have an engineer on my DevOps team every morning she will come in and authenticates of all using her github API key in return vault will give her token to use for the day and that token will expire when the day is done that's what I'm setting up here so then once she has the vault token she's going to export it as an environment variable rather than putting it into her terraform config when she runs terraform it'll use that token to get through their secrets from vaults in this example vault we'll be giving her some unique AWS keys that will expire in five minutes but really she could get all sorts of things from vault like database passwords for instance so when she actually runs terraform apply it's going to pull these database passwords or AWS keys and it's going to put them right out to the state file but guess what in five minutes poof they're worthless because I'm going to set them to expire in only five minutes now if they're expiring in five minutes this might make you think oh well what about later in the day won't that be a pain to use terraform again because she'll have to get the vault token again the answer's no the token lasts for 24 hours so that's just think she only has to login to vault once a day but then she can run terraform over and over again and if it's using a secret that has expired it's just gonna pull a brand new one from vault so these Amazon keys and secrets are going to be dynamically created on the fly every time she uses terraform so yeah that's basically the workflow note that in this workflow zero secrets live in the terraform config file and that means they don't have to be committed to github or anything else that hold secrets they live only in vault github of course isn't the only way to authenticate soval you could use a different authentication method instead of your continuous integration system for instance need to access but that's kind of the general idea the other piece of this idea is like why would I do this well why would we set it up this way well when your DevOps team gets access keys and secrets for vault they're short-lived and they're unique to that person you can set them up to be valid for only an hour a day a week or any amount of time that you'd like and also AWS keys aren't the only secrets that vault can hold it can dynamically create short-lived credentials to your databases to GCP it can SS it can give SSH access and a host of other things centralizing all of this in vaults means that you'll be able to create an audit log of every secret that's being accessed by whom and win which is fantastic for your security compliance story and then someday when that devops team member moves on to some other company by removing them from your github organization you will automatically remove their access from everywhere and you can also go into vault and revoke any credentials that they currently have checked out and since they'll only have been issued to that person specifically there's no issue with revoking shared credentials so revoking their username and password to your sequel database it won't affect anyone else um so these are all very good things some of the most famous attacks in history have been insider attacks and this protects your organization from one it's not necessary anymore in this scenario to give your developers the keys to the kingdom this also protects against accidentally leaking secrets because even if your devops member doesn't encrypt their turf one state file and it's seen all the secrets in the state file were dynamically created in vault and set to expire and then the scope of the problem is limited so this protects you even if your terraform state file is leaked it it how well it protects you basically depends on how quickly you've set those secrets to expire we recommend that you set them to expire very quickly so that basically they can use be used only once by terraform um also hmm I'd like to let you know that the reason I'm going to do all of this at the command-line is we do have a user interface made made by our talented front-end engineers it's available in the open-source version of vault and but today I'm going to be configuring vault using the command-line because out of the box our quick setup cluster is designed to be accessed from a bastion host however turning in the UI is a simple flag in your vault configuration and granting access to it can be done by having your developers on the same AWS VPN so let's look at what I'm going to do here first I'm going to enable the github auth methods so that my DevOps team can get their vault tokens using their github identities as long as they're members of my organization please note that there are many other ways to authenticate the vault including but not limited to OID C which is like Oh auth or a username and password I've just decided to show you get hub here because a lot of the time the people who use terraform at an organization also do have github accounts and then once I've made it so that they can authenticate to vault using github I'm going to make it so that they can get an AWS key and secret for use with terraform and basically what this is gonna do is I'm making it so that when these dev ops team members that when they're terraform config looks at the path of AWS roles dev - role vault is gonna create a new AWS key and secret for them to use that expires in only five minutes so that's what I'm on about here and let's go ahead and head over to the terminal and actually do it just flipping right over here okay here we are looking at the terminal okay there you should be able to see it now all right so first is the first I'm going to create a policy that's this right here this policy basically says that anybody who has this policy available or applied to them is going to be able to read creds from the path of AWS creds devrel and that is the path at which vault is going to dynamically create a new AWS key and secret for the that expires in only five minutes okay now I'm going to enable the github auth method so that's what I'm doing here so right here on this line I enable the github auth method here I say that it can be used by people at the Hashi for organization and this TTL here is basically 24 hours it's seen that whenever vault gives somebody a token using this off method it should last for at most 24 hours and then finally on this line here I'm saying that whenever somebody uses github to authenticate and they're a member of the vault team in github then apply this dev policy to them which again is this policy up here that makes it so they are allowed to read from this packing vault they're not going to be able to see literally anything else involved because this is all of the privilege that they have inside of all so the other piece of this as I had mentioned before was enabling the AWS secrets engine I'm gonna do that I'm gonna clear this episodes a little bit easier to see and I'm gonna paste in all this so basically here I am enabling the AWS secrets engine I'm telling it that when it talks to AWS it should use this access key and secret these are variables command line variables I put my real access key in secret behind them but I don't want to show them on this webinar is I'm sure you can understand and then here this is where I'm setting the credentials that are made up for like the the AWS key and secret ice I'm sending them to expired only five minutes on this line right here and then finally here with this whole thing I'm seeing when you issue credentials I want you to grant them these these privileges inside of AWS those are the privileges that they should be able to do so that's pretty much it for setting up a vault for this workflow that we're going to be doing here let's return to our presentation so I'm going to flip back over to our presentation here and get it back up on the screen for you okay so then last piece of this puzzle now that we've set up a best practices cluster and we've seeded it with the ability to log in and get secrets we need to actually know how to consume those secrets so let's talk about that this is an example of a terraform config file that a dev ops team member will have at this point whether they're using remote encrypted state doesn't matter because the AWS secret they'll be consuming is so short-lived please do expand this analogy to all the secrets that are needed in the terraform config file every secret and the terraform config can be retrieved from vault vault can create unique short-lived secrets for Active Directory all the cloud AWS Azure console a huge array of both sequel and no sequel databases Google Cloud Nomad it can do secrets for use in SSH gene and more being release every day so if you already use vault that not terraform this is how to get started while maintaining your security story if you use terraform but not vault I invite you to consider vault as a way to strongly protect the secrets in your terraform config in state terraform excels at providing infrastructure as code and vault excels at protecting secrets and together they're like peanut butter and jelly let's see I wanted to show you also this this method of pulling secrets straight out of vault and this one showcases tear forms ability to pull secrets from nearly anywhere involved earlier on if we had also configured a secrets engine that gave a short-lived username and password to one of our databases like post press for instance then this is how we would pull credentials for use in terraform again this means that Tara forms resulting state file would be harmless in five minutes if the username and password had been set up to expire in five minutes if there were any long-lived secrets in the terraform configure state I would again recommend using the AWS remote seat instead pointed at an encrypted s3 bucket as I showed earlier on so this is where it all ties together and we take a look at the workflow of that engineer we talked about earlier who arrives in the morning so basically she gets in and she gets a vault tip token using her github identity by running this little command in her command line and boom the response to that first line of code is that she'll get a vault token then she exports it so it doesn't live in her terraform config file and then when she runs terraform applied terraform pulls those short-lived secrets that she needs from vault using the config files they give an example of earlier and they they pretty much get pulled into her form does its work it goes up to the state file and the state file is rendered harmless in five minutes so it's that simple three lines right here alright so in summary we've now watched three how to quickly spin up a best practices vault cluster how to secure it how to see it with secrets and how it can be used to securely provide short-lived dynamic secrets to your DevOps team I hope that in this demo if you're new to these tools you have some sense of what they are and how they can work together to make your life easier and while also keeping security at the forefront if you're not new to these tools I hope you picked up a couple of tips on how to use them together if there's one thing to take away from this is that we recommend that no long-lived secrets live in your terraform configure state files secrets are where vault shines and so it's available in our open source version feel free to use it alright and finally these are the references for you to to free to use that I referred to inside of this presentation the vault reference architecture is where it talks through what kind of Amazon ec2 instances you might want to use if you use this approach and the pros and cons of various things um so I would definitely recommend using that if you're going to use this and best practices vault cluster on AWS this is a link to that github code that had all those pre-made terraform templates so that you can also go and use it if you would like the production hardening guide that I mentioned earlier for locking down the vault instances and such is right there and then also finally as one of our references I do have an example of how to pull AWS keys from vault that's been put up by a very smart colleague of mine named Roger Berlin he found that when he was pulling AWS keys from AWS dynamically you know through vault um sometimes they needed a moment to propagate before they could be used and so he actually built in a little pause of a few seconds where well dynamically generates these AWS keys and secrets there's a pause for a couple seconds and then you actually care for me we'll move on and start using them now that they're available so if you end up wanting or needing an example of that that is right there and that is pretty much it for my webinar today we will be taking questions in just a moment I want to thank you for your attention and yeah we're ready to welcome those questions thanks but we did get a slew of questions so I'm just looking through these right now the first question is from Roger is there a module like the aid of us one used here that's Roger hmm I don't believe there is one that is used for a sure that is hard like is directly pointed at a sure but in the on that second circular config file that I showed you where it's pulling where it's pulling from the database secrets engine it can pull from anywhere involved that supports read access and I'm not sure whether that as your secrets engine has a read for its credentials or a post for its credentials if it's a read then out of the box you can use that same config in order to pull from a sure that's that's what what I can say about it great the next question is in order for a terraform to pull stuff do you need access to the Internet um when this example you do because terraform is using Amazon Web Services which is on the cloud which is like a part of the internet it's hosted in there but you could use terraform to spin up local resources on your own computer in in a different scenario if you weren't using AWS you can certainly use it without the internet next question is the terraform apply stop running in a single thread ah I'm not sure whether it uses parallelism by default or if it is single threaded and because I'm on the ball team it's a more of a black box to me but I do think um if I remember correctly um there is a flag for terraform that lets you control parallelism to some degree so so I think it might be single threaded by default but I'm not sure okay well we'll make sure to get back to some of the questions that we weren't able to answer during this call can we use the term best practices to deploy a vault in a production environment uh yeah you could you would want to make the edits that I had talked about earlier but yes the edits to the instance sizes being at least M 5 larges um the next question is is a little bit broad how would aught Oh unseal feature work so that's a big question that is might be a separate webinar yeah that's probably a separate question but I can't touch on it a little bit um so in the premade terraform config files it adds a vault configuration to the instances and so what you would need to do is go into those files and change it so that it's using an AWS key I actually think that what you would want to do is spin it up the way that I already it's fun and initializes it so you have the initial you know the initial unsealed keys and the vault token and then you would update the config to use the auto unseal method and then do a migration to use the auto and seal keys because vault always does need to be initialized first providing the unsealed keys and such before you bring it over to the you know for the very very first time before you bring it over to using one of the auto and seal methods like kms yeah and and there's also a separate webinar we did recently which was Walt 1.1 how to auto and seal and other new features um well we could send that out as well so the next question is for specific for application specific tariff on skirts do you recommend we keep it in a separate repo along with other telephone resources or in the application specific repo I'm not gonna dare to make a recommendation on that because of how I'm a vault engineer and I'm not on the tariff one team and I can't speak for what they would recommend sorry because research that and and respond with it later though we could ask them yeah um does terraform handle the case where an operation in AWS takes longer than five minutes the pause in the scripts that I linked for Roger Borland I believe that's configurable so you could indeed just set it up to pause more than five minutes this is a loaded question is without becoming a single point of failure I'm hopefully not because you've got it in a cluster where you've got one one active node and then you've got to stand by notes that's why we've got the redundancy there so you know and the vault servers in the best practices architecture are spun up in three different um three different physical data centers you know as I pointed out with the regions and so then they would fail over to the other about the the active server would fail over to the sand by servers in that kind of situation okay so do the master key passwords for a database expire as well after five minutes for resources that do not allow you to change passwords how would that work um so the database secrets engine and many of the dynamic secrets engines involved well all of the dynamic ones where they create a username and password for database on the fly they let you configure how quickly you wants it to expire by default if you don't configure it it's usually about just over a month but in this example I actively made it five minutes and so you can configure how long you want it to last for any of those dynamics secrets engines and that if for some reason you did encounter a situation where you couldn't set them to expire then you would want to use that remote state encryption in order to protect long-lived secrets and be very careful with those but but definitely the recommendation here is to use dynamic secrets in there so that they expire in a short amount of time meaning that if the state the terraform state file is leaked then it's it's scope of damages is much more limited okay so the next question is can the AWS config or route be rotated AWS config inside of the EWS secrets engine yeah you've been updated at anytime that you want to is it possible to try fall and terraform without access to either yes or another cloud provider uh yeah so like maybe you'd be like running it bare metal or something like that and yeah that's totally possible um tarah forum it could be used to spin up the resources locally on your machine or something like that yes so the answer is yes you can run vaults on anything that you want to and you can use sir form to spin it up like the whole idea is that we're trying to be cross-platform for cloud providers and also for gear metal yeah and and I just saw that someone just asked if they can use multi clock for Patrick's so they have three vault servers one on each cloud provider hmm I think that you could but I don't know if I would recommend it because I would wonder how they would talk to each other I suppose that they might need to be opened up onto the internet directly if they were to be networked together and generally I wouldn't recommend that vault is directly available to the internet if it's possible definitely better to have a bastion in front of them um yeah okay can't get secrets if we have multiple AWS accounts and use role based access to switch accounts yeah the AWS auth engine is pretty cool it does have some different options available for how can you use one way is using a role based access where it's like hosted for instance on an ec2 instance that's been launched into a role and then it uses the instance credentials in order to authenticate to vault and that's a pretty cool way of doing it and you can also do a different type of access where you have something assume a role through vault and so yeah it's pretty flexible in that way some for secrets are passed as environmental variables for example the vault token are these captured in the terraform state file um yes they do tend to be captured inside of the turf um State file and that is why we do should set them up to be sugar lift lots of questions here to execute the vault login command you would first need to SSH into the bastion and then to the vault instance correct um in this example yes because we were sort of like we literally spun up the cluster on the fly it was brand new and so it hadn't had further set up yet um so yes in the first example you do you would need to do that but in real life in practice what you would want to do is have your developer on the AWS VPN and when they're doing that then they can set an environment variable of the vault address and then they can set the environment variable of the hook in that they obtain every day and they would be able to do that then from their local computer without SSH into anything okay sometimes can console get installed along with vault to manage the vault cluster is that console licensed separately oh okay um so in this example it is I'm spinning up three console nodes separately and that the three vault servers are talking to so the answer to that is definitely yes and yeah I mean um console is available and in this example we're using the open-source version of console so even if you have like a paid vault if an open-source version of console will work for your use case then yeah before it you only have time for a couple more questions I'd say probably three more questions so I'll just kind of grab this next question is can we seen the user who creates or manage the AWS resources in cloud trail since the AWS keys are generated from vault oh um yes so they're generated by Walt Walt does an API call that is captured by click that's captured by cloud trail and so you can see it does appear to be created by the vault user so you wouldn't see directly in cloud trail the person who was behind the vault who was creating it you would go to the vault audit logs in order to do that so that is where it would be captured just a couple of general questions here what is the version of terraform and does the repo use install vault OSS or vol Enterprise its OSS and and the version of terraform is the one that is out right now it's like perform eleven point eight or something zero dot 11.8 if I remember correctly you know and so that's all the time we have questions for now so thank you everyone for joining the webinar I know there are a couple of questions regarding whether the recording will be sent out yes again the recording will be sent out usually we'll do it within a day or two and if you want more Hasek or resources you could you could go to Hoshi Corp comm slash events we have a couple more coming up particularly on console and Walt so with that we're going to close out the webinar and have a great day thank you thank you right

Channel: HashiCorp

Views: 31,114

Keywords: HashiCorp, Terraform, Vault, HashiCorp Terraform, HashiCorp Vault

Id: fOybhcbuxJ0

Length: 49min 7sec (2947 seconds)

Published: Thu May 23 2019