in this video, we're gonna verbally talk through a real world scenario in a solution for that scenario. And we're gonna apply the knowledge that we have about AWS identity access management about vault policies. What we just learned in AWS Secrets Engine. We're going to reach back and apply Aperol secrets engine. Incorporate that,
and we'll even talk through a cubbyhole response, wrapping
a little background on the real world scenario. Before we get going,
let's assume we have are using the C I server drone because I already used Jenkins is gonna use drone in this example, we have vault. It's set up on a server. At least it's up and running. And then, of course, we have an AWS account
and then we have the admin.
And in this scenario, let's say we want to ensure that all changes made to the production environments hosted in AWS
are done employing infrastructures. A code discipline specifically, let's say terra form scripts need to be run this way. We have good change control traceability that may be needed for auditing scenarios and in various compliance needs. So with that said, what are the first things
and we just did this in the lab as an admin. We're going to create a vault account in eight of us. This is the account that vault itself will use when it needs to talk to AWS. So this is going to need to have that. I am permissions on it. After that, the vault server is going to need some additional configurations.
Let's assume we're using answerable playbooks
to manage how our vault servers set up and configured. So we'll need to make sure to enable the AWS Secrets engine.
And then let's also take advantage of that Aperol secret sentient right, Because we're gonna have drone the application drone talking to vault, and it's gonna be retrieving secrets from vault, and that's a perfect fit for using the Apple secrets and in So we're gonna enable both of those in this theoretical situation.
Then we're gonna create a policy of vault policy for the drone application that
allows it to do certain things like retrieve aws secrets but maybe only retrieve specific secrets secrets that are associate with a particular role. For example, we did easy to admin in the last lab activity. Maybe we we have the same situation, right? This drone is just going to run scripts that are interacting with easy to
in start instances in Amazon.
With the policy set up now, we are going to generate the role I d right. This is from the APA role that is being created is gonna return. It's the role I d and then it's gonna give us a secrets i d
and that. The thing is, the scripts were talking about these scripts are doing that right automatically on the vaults over itself. So what we don't want to do is let that secret I d associate with role float around much, right? It's one thing if we're keeping it in memory about passing them back and forth is kind of dangerous. And let's assume
we don't have a lot of trust
in the network. So what we can do that is take that secret. I d and will use the cubbyhole wrapping approach, and we were actually generated token and wrap that secret idea itself in the cubbyhole.
And then, of course, we're gonna return that token that got generated will call this the answer Beloff token. So that tokens gonna come back over the wire from the vault server as a next step, we're gonna have certain operations running on the drone. See, I sir, we're gonna pass that Ansel authentication token onto the drone. See, I server drone. See, I server
is going to talk to vault.
Using that token, it's going to go through the unwrapping process and then received the secret i d from vault. So now it has both the role i d and the secret I d. Because it was able to go through the unwrapping process and retrieve that secret I D. And that can subsequently configure the drone application itself and say, when you talk to vault,
you're gonna use this role, I d. And this is the secret idea that you're going to use.
Subsequently, the C I CD processes are going to be launched by drone, and the first thing drones going to do is reach out to vault and say I need an access keys to interact with and communicate with AWS and perform what I need to do. Fault is then going to talk to AWS
and return the access keys associated with the account that it just created in eight of us. From that point, the drone jobs will then interact with AWS using those access keys.
So hopefully you saw how we were able to take all these different things we've learned in some of this of subsequent lessons and put them all together to build out a solution that didn't expose our secrets. Moreover, it's a solution where vault is in the loop as faras the retrieval and management of these secrets.
So we can take advantage of auditing that we have in place,
of course, lease expiration. We can put together similar process to automate the lease renewals off the role I d. In the secret i d. When drones talking to vault. And, of course, lease renewals for the different Amazon accounts. That drone is providing KWS.
So if any of those accounts somehow got compromised,
they would be very short lived in time, and they would have quite a bit in terms of restrictions of what they can and can't do.
So to summarize, we walk through a nice little design pattern to manage secrets in a common see I CD set up. Whether you're using Jenkins, eight of us or excuse me drone a Ws Jenkins azar. It really doesn't matter the combination and you see how vault comes into the picture. And we did this by applying our knowledge of
eight of us. I am the vault policies
area secrets engine, the Aperol Secrets engine. And finally, we applied the cubbyhole response wrapping technique to deal with the problem of secure introduction so that somehow the secret I d associate with the role I d could be safely obtained by the drone server. Well, I hope you got a lot out of this
and thank you for joining, and I look forward to seeing you back in future videos.