1. Handling Access & Secret Keys the Right Way in Providers
Everyone, and welcome back to the Kplabs course. So in today’s lecture, we will be looking more into the provider’s configuration. Now, if you look into the sample resources that we have been creating up until now, one thing that you will see is that within the provider TF, we would have stored access and a secret key over here. And this is not always the best approach because there are many instances where you will actually commit this specific file to your git or bit bucket repository, putting you at risk of being compromised once more. And this is the reason why you should never have any credentials within your provider’s For or even within the resources file. Now, what I have done is in fact whatever anyone would have already done; I am very sure of that. That is the configuration of the AWS CLI. Allow me to do AWS with three LS in general. So, if you use AWS’s three LS, it will basically configure or display all of the buckets in the region. Installing AWS CLI is now extremely simple, especially in Linux and Mac.
However, installing this CLI in Windows is also straightforward. All you have to do is download the MSI installer, and that should do the rest for you. Now, one thing that I wanted to show you is that once you have the AWS CLI configured, you don’t really need to put the access and secret key within the provider or TF. Even if you remove this particular aspect and click on Save the TerraForm, the plan will really work great. So let me give you an example. So if I do a TerraForm plan, you see, even if I have removed it, it still works quite well because it takes the credentials from the AWS credentials file. So I already have that path exported. So if you look into the conflict file and the credentials file within the credentials, I have multiple credentials over here, and the default credentials are something that the providers will take if you have not explicitly included the access and secret key code over here. Now, one thing that you have to be aware of is that if you remove the region part, let me quickly remove the region part, and I’ll comment it out.
If you remove the region part, what would really happen is that when you do a TerraForm plan, it will ask you where or in which region you want to create a resource into.So, ideally, you should have the region part and within the providers within the region, you can configure the region to work around it. So this is part one of the provider’s configuration. So, depending on the use case, you can make a variety of provider configuration changes. Now, in certain use cases where you have multiple accounts or where you want to deploy a specific resource in multiple regions, having a default provider’s configuration will not really help. So what we’ll do is wrap up this lecture, and in the upcoming lecture we’ll look into various provider-specific configurations depending upon various use cases that you might face, and we’ll look into how we can solve each of those. So this is it about this lecture. I hope this has been informative for you, and again, if you are storing your credentials with the providers, remove them and make your code security safe. So this is it. I hope this has been informative for you, and I look forward to seeing you in the next lecture.
2. Terraform Provider UseCase – Resources in Multiple Regions
use case. Let’s look into the second use can then to deploy EC2 instances in an account and then want to launch one more Two instances in a completely different account So these are various kinds of atypical cases that are a bit challenging. So let’s look into how we can achieve that with Terraform. So, the first thing that we have been looking into is that we have two resources. Let’s say I have resource one and resource two. I’ll call this an EIP one. So these are the two EIPS.
Now, what I want is that the first EIP be launched in one region. And I’ll say the second EIP should be launched in the second region. So this is my use case. I don’t want both the EIPs to be launched in the US West region only.
All right? So let’s look at how we can solve that. So, before we do that, what I want to show you is that many of you might try having two specific AWS provider configuration blocks. So I’ll say AP. South one. All right. And if I do a Terraform plan, it will basically give me an error saying that multiple configurations are present. Only one configuration is allowed per provider. So you cannot have multiple configurations per provider if you have a configuration block like this. So what TerraForm allows us to do in this kind of use case is that it allows us to have an alias variable. So what does an alias variable allow us to do? Let me put an alias on it, and I’ll say let me give a value called Mumbai, all right? These are now two alias variables. Now, when I do a Terraform plan, you can see the error has gone away.
Now, the Alias variable allows us to have multiple configurations for the same provider. Now, coming back to the use case where you want to deploy this specific resource in one region and the second resource in another region, So what you have to do is reference the resource to a specific configuration, because currently we have two configurations over here. So let’s assume EIP One has to be created in this specific configuration, US West One. And this EIP is another EIP resource that has to be launched in the Mumbai region. So how can we achieve this within the resource block? You must include the provider block here, with AWS as the provider and the alias name. So the alias name is Mumbai. So this is the provider name, and AWS is the alias name. So I’ll say, “AWS Mumbai.” I’ll click on Save, and let’s do a TerraForm plan.
And you see, it is not currently giving us an error. So basically, this would allow us to create multiple elastic IPs in multiple regions. Let’s create a Terraform application. I’ll say yes. And this should create multiple elastics in two different regions. So always remember that if you want to have various different configurations, you can have them for the same provider with the help of the alias block. So this part is quite important. And I’m sure that when you work with Terraforming, the production alias is something that you will be working with on a regular basis. So this is what use case one is all about. Now, we have a second use case where you have two completely different accounts. So basically, you will have multiple access points and secret keys. Now, how will you make TerraFormation with that kind of approach? So let’s do one thing. Let’s discuss this second use case. In the next lecture, we will pause or conclude this specific video. Try this out within your test environment. And once you are comfortable with this, we’ll go ahead and discuss the second use case. So this is it for this lecture. I hope this has been informative for you, and I look forward to seeing you in the next lecture.
3. Handling Multiple AWS Profiles with Terraform Providers
Hey everyone, and welcome back. So, in today’s lecture, we’ll take a look at the second use case, in which we can launch multiple resources in different accounts. In AWS CLI, this is generally referred to as the hyphen-hyphen profile parameter. So let me give you one example. So currently, within my AWS credentials, I have two access keys. One is the default access key, and the second is the second access key. So this access key belongs to account two.
So this is AWS account number two. This, in turn, is an AWS account. Now you want to launch the EIP, which is the first EIP in an AWS account. And the second EIP should launch in a different AWS account using these specific credentials. So let’s look into how we can achieve this. So, in general, if you work with CLI, you will have a hyper-hyphenated profile. So currently my second set of credentials are associated with the name “account two.” So, if I do account two within the profile, it should work out really well.
Now that you want to achieve this similar functionality with TerraForm, we’ll look into how we can do that. So before we do that, let’s quickly destroy the source that we had created earlier where we were creating elastic IP in two different regions. All right, so now it has already destroyed the resource. So let’s go into the provider configuration. And within the provider configuration, there is one additional block that you will have to add, and that block is a profile. So, within the profile block, you must enter the name of the profile to which the access and secret key pertain. So, if you will see, these are the two different sets of access and secret keys. So I’ll name this specific profile in the provider’s configuration. so I’ll say account two. Let’s quickly verify the account, and I’ll click on Save.
So, within the EIP, we’re already referring to the provider, AWS Mumbai, or you can even name it account two to make it easier for us to understand or AWS. All right, so here you quickly change the parameter, and basically now this specific resource belongs to or will look into the provider, which is AWS AW2, and AWS AW2 has a different region and has a different profile parameter. This profile parameter is now account number two. So within the credentials file, it will look into the access key and the secret key associated with account two and launch the resource within a completely different account. So with this type of approach, if you are creating elastic IP, the first elastic IP will be created in account one, and the second will be created in account two. So let’s do one thing: let’s quickly check if everything seems to be perfect.
So I’ll do a Terraform plan, and we are not really getting any errors. So let’s do a Terraform application to just verify if everything is working perfectly. As expected. I’ll say yes. Perfect. So you see, it was created successfully. So this is one of the ways in which you can launch multiple resources in multiple regions, or even in two separate accounts. So this is it. In this lecture, I hope this has been informative for you, and I look forward to seeing you in the next lecture.
4. Terraform & Assume Role with AWS STS
Hey everyone, and welcome back to the KP Labs course. So in today’s lecture, we’ll look into how we can integrate Terraform to achieve the functionality of assuming roles, which is generally done with the help of the AWS SDA service. Now, in a typical use case where there are multiple AWS accounts, a general way of achieving that solution is with the help of delegation. So let’s look at what exactly it looks like. So let’s assume that you have multiple AWS accounts that you have.
Now, instead of having multiple usernames and passwords and multiple access and secret keys associated with each and every individual account, what many organisations or best practises suggest is that you have an identity account where you have a single set of usernames and passwords and a single set of access and secret keys. And through the identity account, you assign a role to each individual AWS account. And this is what best practise suggests. Now, in this type of use case, you don’t have to worry about assuming the role via console because AWS natively supports it. But when it comes to Terraform, there can be a little issue with this type of use case. So in fact, many months ago, having assumed a role with TerraForm was something that created a few issues. But in the latest release, this specific use case is actually solved. So let me give you an example of what I mean by this.
So I have a simple Sts user, and this Sts user has a simple JSON policy. So this is the JSON policy for assuming a specific role. So this is a JSON policy where this STS user is allowed to assume a role with this ARN. So this is a role that is called “KP Labs have an SS.” So let me go to Kplabs have an STS role, and I’ll show you Kplabs have an STS quickly. And I have administrator access to this, as well as full access to Sri. As a result, you can assume that the Kplabs havean Sts belongs to a different account than your user. So with your user access and secret keys in TerraForm, you want to assume this specific role. KP ads have an STS and create the resource in a separate account. So what I have done for this demo is that I have generated an access key and a secret key, and I have fed the access key and secret key into my AWS credentials file. So these are the access and secret keys of the user.
Now, let me go to the console and try an AWS s three LS. And now you see that the permission has been denied. The permission is denied because the userSts user does not really have any other permission other than assuming the role. So if the user wants to create a resource, it has to assume a role, and from those credentials, it can go ahead and create a resource. So how you can do that is, let’s take an example of a CLI, and then we’ll work with TerraForm. You specify the role ARN when you do AWS sts assume role. Now I must obtain the role ARN.
Let me quickly get to the role. So this is the role; I’ll get the role, ARN. I’ll paste the role here, I’ll specify the role session name, I’ll say “skplastifand testing,” and I’ll do an enter. And now you see, what happened was the user assumed this specific role, and it got an access key, a secret key, and a session token. So these are the three things that are important. After you get these three things, you have to use these three parameters to create a resource with the Assume Role permission. Now, this is very easy to do as far as the AWS CLI is concerned, but one of the requirements is to achieve this kind of use case with TerraForm as well. So we want Terraform to create the resource using this access key, this secret key, and this specific token. So this is the requirement.
So let’s look at how we can solve this specific requirement. So I’m in my Atom editor, so let me create a simple file I’ll call EIP PF, and within this I’ll create a simple resource called AWS EIP. I’ll name this my EIP, and within this I’ll say VPC is equal to true. So this is a simple, elastic IP-based resource. Now, all the configuration related to an assumed role has to be done within the provider itself. So I’ll create one more file called asproviders TF, and this is where we will be working with the assumed role-related configurations. So within the provider, I’ll have an AWS provider. The region I prefer, the default region I prefer, is the United States West. Let me just choose the west one. Now if I just click on Save and let me actually go to this specific folder, which is TerraForm iPhone SDS, All right, and let’s do a TerraForm plan. All right, so let’s have Terraform apply as well. And now, as you can see, I got an unauthorised exception because the user does not really have any permission. So you must tell Terraform that it must assume the role, and you must also specify the role ARN. So you assume the underscore role, and within this you specify the role ARN, and the next thing you specify is the session underscore name. So this is very similar to what we used to do in the CLI.
So, let’s go to the role to get the role ARN. I’ll get the role ARN, specify it over here, and you can basically keep it whatever you want. I’ll recommend KP Labs for assistance and demonstration. Perfect. Now I’ll click on save, and now let’s go ahead and do a TerraForm appliance. And you see, it worked perfectly. So this is what Terraform does. This is a fantastic feature in which Terraform can play a role. And then it gets the temporary credentials that we were discussing earlier, the access key, the secret key, and the session token. And it uses those three parameters to then create the resources. So it’s all about Terraform and assumed roles. I hope this has been informative for you, and I look forward to seeing you in the next lecture.
