Use of an insecure channel - AWS
Need
Secure communication channels for data transmission in AWS
Context
- Usage of Terraform for Infrastructure as Code (IaC)
- Usage of AWS SDK for interacting with Amazon Web Services
Description
Non compliant code
provider "aws" {
region = "us-west-2"
access_key = "my-access-key"
secret_key = "my-secret-key"
}
resource "aws_instance" "example" {
ami = "ami-0c94855ba95c574c8"
instance_type = "t2.micro"
tags = {
Name = "example-instance"
}
}
In the above Terraform code, we are creating an AWS instance in the us-west-2 region. The AWS provider is being configured with access_key and secret_key. However, this code doesn't implement any secure communication protocols or cipher suites.
This means that all the communications between the Terraform client and AWS endpoint are susceptible to Man-in-the-Middle (MitM) attacks, where an attacker could potentially intercept the communications, gaining unauthorized access to sensitive data, and possibly even modifying the data in transit.
In addition, the identity of the remote end of the connection (in this case, the AWS endpoint) is not being authenticated. This could allow an attacker to impersonate the AWS endpoint, tricking the Terraform client into sending sensitive data to an unauthorized endpoint.
This is a serious security vulnerability, as it could lead to data breaches and unauthorized access to AWS resources.
Steps
- Use HTTPS instead of HTTP for communication with AWS services
- Enable encryption in transit by configuring SSL/TLS for the communication channel
- Ensure that secure cipher suites and encryption protocols are used
- Implement mutual authentication to verify the identity of the remote end of the connection
- Avoid hardcoding access keys and secret keys in the code, instead use secure credential management solutions
Compliant code
provider "aws" {
region = "us-west-2"
access_key = var.access_key
secret_key = var.secret_key
}
resource "aws_instance" "example" {
ami = "ami-0c94855ba95c574c8"
instance_type = "t2.micro"
tags = {
Name = "example-instance"
}
ebs_block_device {
encrypted = true
}
}
The updated code now uses variables for access_key
and secret_key
instead of hardcoding them directly into the provider block. This is a more secure practice as it prevents the keys from being exposed in the code. The keys can be provided through a secure method such as environment variables or AWS Secrets Manager.
In addition, an ebs_block_device
block has been added to the aws_instance
resource with the encrypted
argument set to true
. This ensures that the EBS volume attached to the instance is encrypted, providing data-at-rest security.
Please note that this code assumes that you are using a secure communication channel (HTTPS) with AWS services, and that you have enabled secure cipher suites and encryption protocols. Also, it is recommended to implement mutual authentication to verify the identity of the remote end of the connection.
Remember to replace var.access_key
and var.secret_key
with your actual AWS access key and secret key, which should be stored securely and not hardcoded into your Terraform code.