 Hello. Yeah. Hi. So, I actually just realized Somebody said that about vague title lines. So, it's actually evaluating Vault, which is a hashy corp solution So, these are couple of Problems, which I'm sure a lot of us might have faced some time or other Saving any publicly accessible secrets. It does not involve saving database credentials because Most of us do not have our databases exposed outside. So, it's S3 keys or if we are doing encryption then our private keys or Then the second problem is generating leased credentials for AWS Any system administrator here would know that once you give Developer a key. It's it's gone forever. Actually, it's it's not for a time So generating those leased credentials by the time Third is once those keys are given in a single a single Stop to actually revoke all those keys or credentials and fourth is how to actually give an audit of You know key generation process or how to actually keep audit of you know How the keys are generated or when they are being generated for whom they are being generated and how they were exist So this is Sort of an architecture of vault I have made this myself. There's an architecture level level on walls documentation with it's it's very confusing So you can access the vault with a set of HTTP APIs. The APIs are quite friendly So no need to actually go there On the left side, there is a barrier the barrier actually I'll talk about the barrier in the next slide So all the keys Whatever data you wish to keep in vault is actually encrypted with an encryption key This one right here. The encryption key is known only by vault. You actually do not know or care about the encryption key The encryption key itself is encrypted using a master key The master key is is given to the user. I'll talk about that also in the next slide Then there is a there's an audit broker which essentially writes all the audit locks and then there's a steel broker which Essentially controls the ACL on the HTTP API Then there's a storage back-end layer So you can write your secrets or your data your key value pair anywhere I mean, it's in the database or in the file system. So this layer essentially controls that So here I am going to explain you about the master key in the previous slide The master key essentially is divided into n number of parts You can suggest in how many number of parts you want to divide the master key The the it's like an example here when if some of us might have a vault in the in a bank local So there is a key which is given to you by the bank There is a bank officer's key and then there's a you can put your own personal key in the vault. So To actually unlock the vault the banks vault you actually have to supply all three keys At a single point of a time then only you can unlock the vault But to lock the world you just have to push the door and it simply locks, right? But in vault you can actually decide that how many parts of the keys you need to have to actually do the Unlocking so I mean you can ask the wall to give n out of n I mean all the parts have to be there to actually make wall to actually be able to unlock the world Or you can supply that one or two out of n are enough to actually unlock the world It totally depends on your security model So I am going to show you a basic Couple of commands which you can probably run on CLI yourself So is this visible to all of you? I mean should I increase the font size or this is fine Okay, so on one part I have vault running so it looks something like This I mean it tells you that it's running on so and so port and I mean Nothing is here to actually explain. So I'll just move on This is a basic setup where I have actually initialized the vault with this command So you can see that I have said that okay, there should be three parts of the Master key, but only two parts are actually required to unseal a vault So here actually prints all three parts of the key And you need you should be giving all three parts to different people not to one single person to actually Unseal you actually for example here. I'll show you how to actually unseal So I'm so vault is Stateful so I've sealed I've unsealed a vault with one part. So it actually shows that Out of two one key part has been supplied, but it is still sealed So I take another key and I supplied with here So now it says that okay vault is Unsealed now sealed is false and all the I mean parts are there. So it's sealed now. So I can actually write something for example, I can write a hello and What Okay, it's it's still not authenticated so Here I can see that here is the authentication key So I do vault or It's authenticated And now I write It's a written and now I can also Read So I just And I get a value So any key in the vault has to have a Leased least time. I mean you can't have a unrestricted Secret inside a vault. It has to have a time. This is the default time 768 hours for some reason So I can Seal the vault once again Here sealing does not require any key or anything And if I try to read It once again, it shows a a five or three So there are two ways in which you can use vault With your application One is the sealed approach. This is for some reason the Suggested Mechanism by vault. I I haven't been able to get anybody from vault to talk about it. So I don't know why this is the The standard approach wherein I Follow this approach so here they tell us to keep vault always unsealed and only seal it if a threat is realized Which I'm I'm sure you would not agree. I mean threat does not come Uh after telling us and this is a unsealed approach where Uh, you do a deployment From the app and you wait the application Poles the vault constantly and it waits Uh For the vault to unseal itself Then some some release engineer or some Jenkins script or some deployment script would actually go and unseal the vault And then application or the release script itself would seal the vault After it has read whatever See keys or secrets it needs to read to continue its functionality You might have realized that uh in the cli as soon as I generated The keys for vault it actually printed all the keys in the terminal itself, right? Somebody might argue that that's an unsafe way to distribute the keys So because uh whoever whichever sys said when actually instantiates the vault knows all the keys So, uh What you can do is uh, you can encrypt the keys Like this is the initialization process And you can actually supply your pgp keys so that as soon as it spills out the The unsealed keys it actually encrypts them And it prints the encrypted part only so There are three users a b and c I have given an example of keybase.io Right, that's uh inherently integrated with vault So you create your own account on keybase or or you can specify your open pgp name or id here And the a b and c persons will give will get three keys three parts of the keys with the key parts When encrypted with their own uh public key, uh, these are a couple of uh best practices that we have realized uh Since we have been using vault once uh one is that uh, there are a lot of acls, uh, which you can use with vault There there's a github api There's I think a twitter api. There's uh, you can have custom sttp integration. There's ldap. There's oauth But uh, all of those come with their own vulnerabilities So it has its own uh token based authentication system You can create policies and tokens and and it's very easy. It's a all json based So it's better to use that Because all the acls they come with their own vulnerabilities Uh storage backend. So the default storage backend does not govern that Which acl or which person gets to read or write what part of the storage? It's like ac linux here So you actually there is a storage backend called cubbyhole, which actually links acl with the part of the storage So you can say that these five keys can be uh read or write by this person Then uh, your storage backend is itself Not safeguarded by the world just the entry and the exist exit process is safeguarded So it's better to save by your storage engine. I'm I've given a screenshot of Uh, what what is the easiest one of the easiest ways you just use our amazon ebs with the Here is the encrypt this volume tick So it encrypts the volume and it keeps the keys of encryption in amazon kms So you can have your own storage back ends and it's better to Uh safeguard your storage back ends also uh High availability for production evolved supports cluster setup So I haven't written the steps here, but the steps are fairly easy. You can it's just a json configuration uh You should be using uh high availability back end as well For example, uh, writing the bald secrets in a in a disk space is not encouraged because the disk itself the disks are uh Are I mean easily destructible So you write something on console, which is again hashy corp solution So they go really uh well together or or myc Cole hs solution or or or on an nfs or Efs amazon efs elastic file system or something similar, which is uh, which is scalable or which is which is Highly available These are the things So philip actually told me to cover this as well. I mean these are the things which are outside threat model So it doesn't look like that vault is a single system with which you can do. Um, you can secure everything and anything so I mean the algorithms with the the chamois algorithm is actually uh, uh The algorithm with which the keys are separated into multiple parts. So that algorithm the stdp is the Instance and os philip it is those are obviously outside the threat model the storage back end Somebody runs away with your hard drive. Those are obviously outside. Uh walls threat model Uh, thank you. That's all there is to it. Let me know if you have any questions Hello Okay. Yeah. Hi. So, uh, let's say if you're using asymmetric, uh, encryption like rs or something And your private key is let's say split it into multiple parts And let's say the way you have said for the key distribution, you are using keybase.io So use the same pgp and keybase.io and distribute the keys So let's say we don't really need what and we can do in a very traditional way then traditional way being that like because my private keys split into multiple parts Let's say three people are there. So I divide into three parts But the three parts, uh So, how do you split the key into three parts without an algorithm? I mean if you do for example, key length is 256 or 4096 or bit So you divide the three parts And then all then first and third person cannot Uh, you know club and open the vault right the the all everybody has to be there. Absolutely right But in the shamir secret algorithm The any two person if you specify the threshold as two then out of those three any two people can open the vault I I'll just repeat once again. For example, uh, your key is abcd, right? Now you abc you divide the key into three parts ab and c You don't the first and the last person are there in the room. They provide a and c It will still not unlock the wall right because b is not there Right, but in in the in the algorithm, which splits the keys the abc is not divided by ab and c It's a rather divided as ab bc and ac Okay, so two people need any two people can actually Combine come together and Open the vault and the algorithm goes On like that, right? So if you go over the traditional way, you're splitting algorithm has to be really good enough to cater any n by m division Of the key So even that is simple. Uh, so let's say if that is divided by three So let's say with each one of them. I keep give them two parts of the key Not the third part of the key So let's say if he is having two parts any two people can go and match the three combinations, right? But the joining algorithm is something which is known to you exactly here the joining algorithm something which is not known to you Okay, right. So any two parts if even if you have two parts It will only work with vault. It will not work with any other system because the joining algorithm is not really open It's a variant of chamois secret algorithm, but the algorithm itself is not known Okay, I obviously you can go and study the algorithm and But I agree you're right Hey, sure. Yeah, right left left left left. Yeah, hi Hey, what's up? Sorry. So I just wanted to understand why you're using wall to Basically have this authentication mechanism to access your db or only for deployment access my like accessing the db Or for deployment rolling strategies only Uh, why do I want that? Yeah, where are you using it? Basically? Where am I using so I am from patm? No, no I can't really see where I'm using it But uh where I would like to use is it something is I can tell you. Yeah, for example, uh, so you have uh, we have something you have I let's let's let's take an example of adhar or uadi. So I'm sorry Let's take a better example. I guess. Yeah, so you want uh, somebody to send you a data Right in a secure way. So you give your rsa public key to that person, right? And the api accepts the data and uh, decrypts the data and does something with it So the private key is something which you need to keep somewhere, right? If private key is compromised and anything can happen Where do you see that? Save that private key You can't save that private key in database because it's open You can't save that private key on the system itself because Uh, it's docker and those edges where the the instance goes down anytime Where do you see if the private key that is the question you can't save the private key in your source code also, right? So where to save that data is the question Okay, that that is where you were because you also mentioned one of the slides over the storage backend and the world integrated within So I thought that probably for every dp request you make you have to unseal and then fetch the data that uh, so Vault uh, encourage you see you to do that also. You can use encryption as a service also Okay, right? So as soon as you are saving the data inside dv you take it via vault and then you bring it via vault You can do that So basically for all the operations on the dv. I can just set up vault Absolutely, but that that would increase a lot of computation processes That would mean a lot of computation process So what we generally say is so I generally say this is uh, whatever secrets you need to have to encrypt other secrets For example, if you have to encrypt the whole database itself, right? So it's better to encrypt the whole database or the strings and then keep the encryption key with yourself Uh, it's just like pgp, right? You uh, you send arbitrary long data Overnet work. You don't encrypt the whole data with rsa key You encrypt the whole data with a symmetric algorithm And the symmetric algorithm key is something you encrypt with rsa Right and you and you save that key securely Right. So this is something which I recommend. Right. Yeah. So uh, that's also the thing like for example when we create the secret file Okay, so we usually just like don't commit it at all and then we just go to production and then use an scp to upload it over there And then keep it of course That's one way to do it But then I think what is what would bring in an acl along with it like for example, everyone who's coming in can have a different secret file I mean The second line was that uh, you scp the file from your system right now the system has the file Right. I mean that is the okay problem. The system has has ever had a file Right. It shouldn't even have had a file anytime in the whole uh history Okay, you generate you keep the file on the server itself you generate it there You save it in the world and you remove it Okay, cool. Thanks. Sure I'm I'm sorry. We have to stop questions because we're really running out of time. Shreya is going to be available It's the coffee break now