Monday, February 27, 2023

TERRAFORM LOCAL & REMOTE BACKENDS AND STATE FILE

 





                     TERRAFORM BACKENDS:
This is the base foundation that terraform use to persist configuration file. 

                     TYPES OF BACKEND

LOCAL BACKEND:
Here, the state file is stored in the local machine within the the configuration folder for Terraform to make use of (i.e Local Backend)

HANDS-ON:

Lets deploy files in the local backend and to achieve this, we create two environment files that have same configurations and we the declare the path. For this project, we use "ubuntu 18.04" O/S.


STEP 1:
Create a folder called "local-Backend"

STEP 2:
Within the folder, lets create a "dev.tfvars" file and in this file, you have the below configuration:

dev-vpc-cidr-block = "10.0.0.0/16"
dev-vpc-instance-tenancy = "default"
dev-subnet-1-cidr-block = "10.0.1.0/24"
dev-subnet-1-availability-zone = "us-east-1a"
dev-subnet-2-cidr-block = "10.0.2.0/24"
dev-subnet-2-availability-zone = "us-east-1b"
key_name = "cicd"
ami = "ami-02***eb42***0e"
instance_type = "t2.micro"


STEP 3:
Lets create another file "preprod.tfvars" and in this file, you have the below configuration:
dev-vpc-cidr-block = "10.0.0.0/16"
dev-vpc-instance-tenancy = "default"
dev-subnet-1-cidr-block = "10.0.1.0/24"
dev-subnet-1-availability-zone = "us-east-1a"
dev-subnet-2-cidr-block = "10.0.2.0/24"
dev-subnet-2-availability-zone = "us-east-1b"
key_name = "cicd"
ami = "ami-026****eb*****90e"
instance_type = "t2.micro"

STEP 4:
Create a file "provider.tf"and in this file, you have the below configuration:
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 4.0"
}
}
}

# Configure the AWS Provider
provider "aws" {
region = "us-east-1"
}

STEP 5:
Create a file "variable" and in this file, you have the below configuration:
# dev vpc cidr block
variable "dev-vpc-cidr-block" {
description = "development vpc cidr block"
type = string
# default = "10.0.0.0/16"
}

# dev vpc instance tenancy
variable "dev-vpc-instance-tenancy" {
description = "development vpc instance tenancy"
type = string
# default = "default"
}

# dev vpc subnet 1 cidr block
variable "dev-subnet-1-cidr-block" {
description = "development subnet 1 cidr block"
type = string
# default = "10.0.1.0/24"
}

# dev vpc subnet 1 avialability zone
variable "dev-subnet-1-availability-zone" {
description = "development subnet 1 availability zone"
type = string
# default = "us-east-1"
}

# dev vpc subnet 2 cidr block
variable "dev-subnet-2-cidr-block" {
description = "development subnet 2 cidr block"
type = string
# default = "10.0.2.0/24"
}

# dev vpc subnet 2 avialability zone
variable "dev-subnet-2-availability-zone" {
description = "development subnet 2 availability zone"
type = string
# default = "us-east-1b"
}

variable "ami" {
type = string
description = "prod instance ami"
}

variable "key_name" {
type = string
description = "prod instance key name"
}

variable "instance_type" {
type = string
description = "prod instance type"
}

STEP 6:
 Create a file "ec2.tf" and in this file, you have the below configuration:
resource "aws_instance" "prod-vm" {
# (resource arguments)
ami = var.ami
key_name = var.key_name
instance_type = var.instance_type
user_data = file("webapp-deploy.sh")
subnet_id = aws_subnet.dev-subnet-1.id
#vpc_security_group_ids = [ "aws_security_group.Development-SG.id" ]
tags = {
Name = "Dev-vm"
}
}


STEP 7:
Create a file "network.tf" with the configuration below:

# Development vpc
resource "aws_vpc" "dev-vpc" {
cidr_block = var.dev-vpc-cidr-block
instance_tenancy = var.dev-vpc-instance-tenancy

tags = {
Name = "dev-vpc"
}
}

# Development subnet 1
resource "aws_subnet" "dev-subnet-1" {
vpc_id = aws_vpc.dev-vpc.id
cidr_block = var.dev-subnet-1-cidr-block
availability_zone = var.dev-subnet-1-availability-zone
tags = {
Name = "dev-subnet-1"
}
}

# Development subnet 2
resource "aws_subnet" "dev-subnet-2" {
vpc_id = aws_vpc.dev-vpc.id
cidr_block = var.dev-subnet-2-cidr-block
availability_zone = var.dev-subnet-2-availability-zone
tags = {
Name = "dev-subnet-2"
}
}

# Development vpc internet gateway
resource "aws_internet_gateway" "dev-vpc-igw" {
vpc_id = aws_vpc.dev-vpc.id
tags = {
Name = "dev-vpc-igw"
}
}

STEP 8:
Create a file "Sg.tf" and in this file, you have the below configuration:
resource "aws_security_group" "Development-SG" {
name = "Development-SG"
description = "Development-SG"
vpc_id = aws_vpc.dev-vpc.id

ingress {
description = "TLS from VPC"
from_port = 80
to_port = 80
protocol = "tcp"
#tfsec:ignore:aws-vpc-no-public-ingress-sgr
cidr_blocks = [ "0.0.0.0/0" ]
#tfsec:ignore:aws-vpc-no-public-ingress-sgr
ipv6_cidr_blocks = [ "::/0" ]
}

#tfsec:ignore:aws-vpc-add-description-to-security-group-rule
egress {
from_port = 0
to_port = 0
protocol = "-1"
#tfsec:ignore:aws-vpc-no-public-egress-sgr
cidr_blocks = ["0.0.0.0/0"]
#tfsec:ignore:aws-vpc-no-public-egress-sgr
ipv6_cidr_blocks = ["::/0"]
}

tags = {
Name = "allow_tls"
}


STEP 8:
"cd" into the path (Local backend) where your files are located.

STEP 9:
Run the terraform commands
-Init
-Validate



-plan

Kindly ensure you provide the path "terraform plan --var-file prod.tfvars" and enter the value manually.





-apply



-destroy
In order to destroy run "terraform destroy --var-file prod.tfvars"



REMOTE BACKEND:
This is used to manage the state file with an S3 bucket and Dynamo DB table to lock the state file. We can enable encryption in flight as best practice and this is AWS managed. Also, we can enable access logging to capture all the activities in S3 bucket. All these stated are atypical of local backend. 

For example:
With the STATE FILE located in S3 Bucket, we can explicitly deny the permission by enabling OBJECT LOCK AND VERSIONING, just so that each time software engineer makes changes they will not be able to delete the STATE FILE.

             BENEFITS OF REMOTE BACKEND 

Collaboration: 
Multiple users can access at the same time.

Scalability:
An infrastructure deployment grow in size overtime and with the use of s3 bucket to store the state file, a more scalable data is best managed. 

               


Congratulations, you have successfully deployed a local variables and values 

NB: If you successfully deploy this hands-on, kindly leave a comment and feedbacks. 😊


No comments:

Post a Comment

CONFIGURING A PHISHING CAMPAIGN IN MICROSOFT DEFENDER.

Configuring a phishing campaign in Microsoft Defender (specifically Microsoft Defender for Office 365) involves creating a simulated attack ...