In this chapter, we're not going to write any code. Instead, we're going to learn how to use AWS Secrets Manager product. So if you remember, in the chapter 6, when we developed the WAPI voice assistant, I told you that the plan is to white label Vapi's API and allow our organizations to bring their own keys. Now, I think we all kind of understood why we need that. It is because if you have a single VAPI API key, then you have only phone numbers which are scoped to that API key.
Same with assistants and same with tools and same with knowledge base. So the entire knowledge base, which now you know what it is, is scoped under VAPI API, a single API key. So in order to allow each of our organizations to have their own phone numbers, their own assistants, we need to white label VAPIS API. And in order to do that, we need to allow them to add their own API keys. And then this will allow each of our organizations to have encapsulated knowledge bases, tools, assistants, and phone numbers.
And while we understand the concept behind that, there is this very important method of how are we going to store their API keys. So I have decided to use the AWS Secrets Manager. We're going to start by creating the AWS account and then we're just going to follow the steps I have outlined here to make sure Secrets Manager is ready to use within our app. So let's start by creating AWS account. Head to AWS website, you can see the link on the screen, and create an account or sign in if you already have an existing account.
If you are signing in for the first time or it's been a long time since you've signed in inside of AWS. You need to remember that there are two ways you can sign in. You can sign in using the identity user or you can select the root user. So, what is the difference between the two and why is AWS seemingly strict on preferring identity users instead? Well, what's important for you to know is that in a real world example, where you would work for a company which uses AWS, you will never get the root user access.
Instead, you will have your own identity user which has basically limited permissions. The reason behind this is if a company uses AWS, they are more likely to use hundreds if not thousands of their services. And imagine the catastrophe that can happen if someone who is with evil intentions gets access to the root user and crashes all of those services, right? So that would be very bad. That's why whenever they give access to employees, they use IAM user access.
But if you're developing this for the first time, you've just created AWS account, you don't have this, right? You only have the root user. Or if you're like me and you're just solo developing this for yourself you're not using your company's account then you know your email and you know your password So feel free to select root user and use the email and password you just created. Once you are inside of this dashboard, your might look a little bit different than mine simply because I already used this to create the secrets manager. So you can see that I have some recently visited items.
You probably don't have those. What I want you to learn from here is how to find out your region and how to check if your account has any credits inside. So when you look in the upper right corner here, under your account, you will find if you have any credits remaining right here and how many days you have remaining. But you can see that even if these days expire you still have free plan if you didn't spend the credits. So I have no idea how I got this.
I think this is the default for every new account. And I'm pretty sure AWS has like a ton of programs. If you're a student or something, you can get free credits. And For your region, you can see it right here. So click here and just kind of try and be aware of what your region is.
So for me, it's this US East one. I'm not sure if that's the default. It wasn't pre-selected for me. I have no idea, but I developed the app on this region. So just be aware, this is the region you're using.
Now let's go ahead and let's see what is the next step. So we just did step one, creating the AWS account. Now let's create that user within our root account that will only have permissions for certain things. So let's go ahead and let's search for IAM services, manage access to AWS resources. And now inside of here, go ahead and select users.
And you can see I already have one user. You probably don't have this because, well, if it's a new AWS account, you've probably never created this. So let's go ahead and learn how to create this user that we're going to need, which will have access to secrets manager. So let's click create user right here and let's go ahead and give it a name. So I'm going to call this echo secrets and I'm going to give it a suffix of bot because this will only be used as programmatic access.
So I won't check this. I will leave this empty because this isn't a user. This isn't a person. We're only creating this so that we can later generate access keys for this specific user and then use them inside of our project. This way, even if those keys leak, they won't have access to our entire AWS.
And as far as I know, this is the only way you can connect to AWS. You need to create a smaller subset of permissions like we are doing right now. So echo is the name of our app and then secrets as the what this permissions will be about and bot to indicate this is not a person. This is programmatic access. And let's click next.
Now for the permission options, go ahead and select attach policies directly. And in here, we don't really have the policy that we need. So let's click create policy. This will open a whole new tab here and now we have to create a new policy. So I like to use the visual option if you are super you know capable of doing this JSON option know what you're doing sure you can use it but I just like visual I think it's easier to work this way.
So let's choose a service. This will be secrets manager. So let's select that. And now we have to add the values. So the effect is allow.
Let's go ahead and go inside of read. So the first thing we're going to do is we're going to allow getSecretValue. And then in the right we're going to allow createSecret. So already we can create new secrets and we can obtain them. Let's also do put secret value and let's also do update secret.
Like that. Delete secret itself won't be needed really because even if user disconnects their WAPI integration we're not going to delete their secret we're just later going to update it. And now inside of here we need to create a specific resource. So let's go ahead and click add ARNs and inside of here you have to add your region. So what is the region?
Well this one US East 1 right that's the region I'm going to be working with. So US East 1 like this. If you really want to, you can also select any region. So you can maybe try this later if for some reason the region you have entered is not working. And now for the resource secret here, we're going to go ahead and do the following tenant forward slash and then an asterisk.
So basically, we're going to only allow this under this specific resource secret. So tenant is basically organization. So we are creating a wildcard access here so that the secrets can only be stored under this specific format. And let's go ahead and click add ARNs like this and I think that that should be all let's go ahead and click create policy and now this policy will take some time to be created here. So I think even if you try and search for it, so echo tenant secret manager, it might not even be available immediately here for you.
But that's okay, that's what happened for me the first time, it took some time to be created. So you can either refresh policies here and see if it appears then if not wait maybe 5 to 10 minutes. Let's go ahead and click view policy if you have it available fine if you don't but let's just review if everything here is correct So the permissions are only for secrets manager and we can only read and write. And for the, let me try and find the ARNs. Okay, it's right here.
ARNs are right here. Okay. And we are only doing it under US East one resource here. Now what we have to do, we have created this policy and now we have to go back, remember, because we were developing the user. This should be in your previous tab.
So you can even start this whole user process again. It doesn't matter, right? So just go ahead and specify user details echo secrets bot. Don't check this. Click next here and then in here you have to find that new echo policy.
The problem is here as you can see it's not really appearing for me. But let's see I just hit refresh and there we go now I have it. So now I can select it. Even if you still can't do it I would recommend maybe waiting 5 to 10 minutes and try refresh again. But even if it's not appearing then you can continue without adding permissions you can add them later right and now let's go ahead and click next here and I think that everything here is fine so user details echo secrets bot permission summary echo tenant secrets manager access let's go ahead and click create user here and there we go I just have my new user echo secrets bot perfect now that we have this we have to create API keys that will be used to access this echo secret bot.
So let's go ahead and click create access key. And in here, what we have to select is application running outside AWS. Now in here, you're going to get the warning to use IAM roles anywhere to generate temporary security credentials. I did not have to do that and I think it might be a little bit of an overkill to do so. And I'm not 100% sure, but I've heard that AWS likes to push these roles simply because then they have their own courses on that and templates and certificates and whatnot.
But it's more than enough for you to just select application running outside of AWS and click next here. And for the description tag value, let's go ahead and simply say echo project, I guess. Or maybe we can specifically say echo convex backend. I'm not sure it really matters, but let's just add something in here. And now in here, you're going to have your access key and your secret access key.
Let's copy both of them. And I know I said we're not gonna write any code. Well, technically this isn't code. We're just adding to our backend environment.local here. So let's go ahead and let's add, let me see.
So this is AWS access key ID. And the other one will be AWS secret access key. Let's go ahead and copy the secret access key and let's paste it here and let me just double check that these are that this is how you name these so AWS access key id AWS secret access key and also AWS region will be US East 1. So the same one that we have defined multiple times. You saw that when I logged in, it was US East 1 here.
And inside of the Echo Secrets bot, I think that you will see that we have only set this permission maybe this policy to be here it is US East one so make sure that you are using the same region here So make sure that you have added these three inside of your packages, backend, environment, local, and now copy them and head inside of your convex here, your project settings, environment variables, add and paste all three and click save all, Just like that. And I believe that's everything we had to do. We created the IAM user, IAM policy. We created the ARN for tenant wildcard. We attached the policy to the user and we created the access keys for the user.
And then we stored both the keys and the region in environment local and in the convex cloud. So now we are ready for the next chapter when we are actually going to install the AWS secrets manager package in our project and use it to store some API keys. Amazing, amazing job. Of course, if something goes wrong, if it ends up being the case that something's not working, we can just try again. But I'm 99% sure we did everything correctly here.
I believe that marks the end of this chapter. There is no code to review here because we didn't write any. So yeah, I think that's it and see you in the next chapter.