Welcome back. In this lesson, I'll review the credential configuration options that you can use to allow Terraform to correctly and successfully authenticate into your own AWS accounts. If your authentication set up is broke, Terraform is not going to be able to authenticate, and this will mean no infrastructure gets provisioned. So, understanding how to do this successfully is essential to moving on. Let's begin.

There are basically three different approaches to configuring your AWS account credentials to allow Terraform to connect and authenticate successfully. The first approach is to wire the credentials directly into the Terraform template file. In the example given here, the AWS provider is configured with both an access key and a secret key.

Now, although this approach is probably the quickest and easiest approach, it should be done so with care since it is considered bad practise or, at least, not good practice if you were to version control this file containing the credentials. The last thing you want is AWS account credentials floating around in your version control system, particularly ones that can perform infrastructure changes.

As you will see in the following two slides there are better alternatives that allow you to extract out the credentials and store them elsewhere. Pausing briefly here, regardless of the AWS credential management approach you end up using, within the AWS account you should create a dedicated IM user with programmatic access enabled.

For this user account, make sure to grant at least privileged based permissions, as this limits the potential blast radius that Terraform will have within the AWS account. Granting the Terraform AWS IM user full admin access within the AWS account might be convenient at first but it will likely be overkill, not to mention dangerous as Terraform effectively has granted permissions to do any and everything within the AWS account.

If, for example, you need it to only build a VPC, Subnets, Route Tables, and deploy EC2 instances of, say, a particular instance type, then create a custom IM policy and assign it to the IM Terraform user that allows just that and nothing else. The second approach is to leverage environment variables. The Terraform CLI Executable is designed to scan for and detect the presence of these environment variables. If detected, they will be used.

Clearly, this approach is better from the perspective of version control. With this approach, the main.tf file, as previously configured, could now safely be committed into version control, since, the AWS credentials have been extracted out and away from it. The third approach is to store them, as you may have already done so if you're a user of the AWS CLI, on the local file system, in a credentials file.

The AWS Terraform provider, for example, can be configured via the shared credentials file attribute having it pointed at an existing credentials file, such as the one used in this example. For those who may be unfamiliar with the AWS CLI, the file path used within this example is actually a pointer to the same creds file as used by the AWS CLI. Note; the AWS CLI is not a prerequisite for the Terraform CLI. Regardless, the Terraform CLI can be configured, as seen here, to reuse and share the same creds file created and managed and used by the AWS CLI.

Note; if all three types of credentials are used, then the 3.X version of the AWS provider preferences static credentials first followed by environment variables and then, lastly, shared credentials. The same order is just given in the three explanations. The next example is really just a derivative of the previous example. Here, when we use and set the profile, together with the absence of the shared credentials file attribute, implies that the files will be sourced from the current users home/.aws/credentials file. Again, the same one that is used and managed by the AWS CLI.