Forem: iamtito

Clickjacking attack Protection

iamtito — Fri, 03 Jul 2020 11:36:44 +0000

Clickjacking, also known as a “UI redress attack” is a malicious technique for tricking a user into clicking on something different from what the user perceives, the attacker tricks the users with invisible or disguised webpage elements. This example from OWASP clearly explains it "imagine an attacker who builds a web site that has a button on it that says “click here for a free iPod”. However, on top of that web page, the attacker has loaded an iframe with your mail account and lined up exactly the “delete all messages” button directly on top of the “free iPod” button. The victim tries to click on the “free iPod” button but instead actually clicked on the invisible “delete all messages” button. In essence, the attacker has “hijacked” the user’s click, hence the name “Clickjacking”."

Preventing Clickjacking

Sending the proper Content Security Policy (CSP) frame-ancestors directive response headers that instruct the browser to not allow framing from other domains. (This replaces the older X-Frame-Options HTTP headers.)

Content Security Policy replaced the X-Frame-Options, this sends an instruction to the browser to not allow iframe from other domains. However, you can set this up for some exceptions in your application server config

Apache Config

Deny

Header always append X-Frame-Options DENY

Will be configured as

Header always append Content-Security-Policy "frame-ancestors 'deny'

DENY all but not self

Header always append X-Frame-Options SAMEORIGIN

functions as

Header always append Content-Security-Policy "frame-ancestors 'self'

Allow self and multiple domains

Header always append Content-Security-Policy "frame-ancestors 'self' https://www.example1.com/ https://example2.com/;"

Nginx Config

Deny All

add_header Content-Security-Policy "frame-ancestors none;";

DENY all but not self

add_header Content-Security-Policy "frame-ancestors 'self';";

Allow from multiple domains

add_header Content-Security-Policy "frame-ancestors self example1.com example2.com;";

Test

👇click on HTML and change the domain to your domain

Tools for checking your headers

Reference and helpful links:

https://owasp.org/www-community/attacks/Clickjacking
https://www.keycdn.com/blog/http-security-headers
https://content-security-policy.com/examples/

Ansible Dynamic Inventory

iamtito — Fri, 03 Jul 2020 03:48:42 +0000

Static inventory will not serve the needs when tracking and deploying to multiple sources with hosts spinning up and shutting down in response to business demands. The solution to such a changing infrastructure would be ansible dynamic inventory. To accomplish this, you will need a cloud provider ini file (e.g aws.ini) and ec2.py (which ansible use to communicate to the AWS API to fetch the metadata for all the instances). This post focus on AWS(Amazon Web Service).

ec2.ini file provided by Ansible. All the cloud provider .ini can be found here https://github.com/ansible/ansible/tree/stable-2.9/contrib/inventory

ec2.py: EC2 external inventory script which dynamically fetches data from AWS API

To set up the ec2 external inventory script, copy the script to /etc/ansible/ec2.py and run chmod +x /etc/ansible/ec2.py. You will also need to copy the ec2.ini file to /etc/Ansible/ec2.ini. Then run ansible-playbook normally, the --limit args can be parsed.

To make a successful call to AWS API, configure boto. There are a variety of methods available, you can add setup your aws credential by setting up your ~/.aws/credentials or export the following environment variables:

export AWS_ACCESS_KEY_ID=’mYaWeSoMeAcCeSsKeY′
export AWS_SECRET_ACCESS_KEY=’IcAnToTaLlYpUtMySeCrEtHeRe′

Set up a few more environment variables to the inventory management script such as

$ export ANSIBLE_HOSTS=/PATH/ec2.py
$ export EC2_INI_PATH=/PATH/ec2.ini

This variable sets ansible-playbook to use the dynamic EC2 script instead of a static /etc/ansible/hosts file. Open up ec2.py in a text editor and make sure that the path to ec2.ini config file is defined correctly at the top of the script:

EC2_INI_PATH instructs ec2.py where the ec2.ini config file is located.

Make the script executable and test it by running
./ec2.py –list

$ ./ec2.py --list
{
  "_meta": {
    "hostvars": {
      "1.9O.1OO.12O": {
        "ansible_host": "1.9O.1OO.12O",
        "ec2__in_monitoring_element": false,
        "ec2_account_id": "19OP23I42OF3",
        "ec2_ami_launch_index": "0",
        ....
        "ec2_tag_App": "olonje",
        "ec2_tag_Env": "Staging",
        "ec2_tag_Name": "Bami Gbe",
        "ec2_virtualization_type": "hvm",
        "ec2_vpc_id": "vpc-IaMhIdDeN"
      },
      "4.OOO.122.1OO9": {
        "ansible_host": "4.OOO.122.1OO9",
        "ec2__in_monitoring_element": false,
        ...
        "ec2_key_name": "emi-moni-profile",
        "ec2_root_device_name": "/dev/xvda",
        "ec2_tag_App": "ounje2",
        "ec2_tag_Env": "prod",
        "ec2_tag_Name": "Production Stack",
        "ec2_virtualization_type": "hvm",
        "ec2_vpc_id": "vpc-IaMhIdDeN"
      }
    }
  },
  "ami_1k02nd83js84k6apO": [
    "1.9O.1OO.12O",
    "4.OOO.122.1OO9"
  ],
  "tag_App_olonje": [
    "1.9O.1OO.12O"
  ],
  "tag_App_order2": [
    "4.OOO.122.1OO9"
  ],
  "tag_Env_Staging": [
    "1.9O.1OO.12O"
  ],
  "tag_Env_prod": [
    "4.OOO.122.1OO9"
  ],
  "tag_Name_app_Worker": [
    "1.9O.1OO.12O"
  ],
  "tag_Name_Production_Stack": [
    "4.OOO.122.1OO9"
  ],
  "vpc_id_vpc_IaMhIdDeN": [
    "1.9O.1OO.12O",
    "4.OOO.122.1OO9"
  ]
}

To fine-tune the output and other features that aren’t applicable refer to the ec2.ini file. For multiple AWS accounts, you can pass --profile PROFILE name to the ec2.py script.

$ cat ~/.aws/credentials
[default]
aws_access_key_id = <default access key>
aws_secret_access_key = <default secret key>

[profile tito]
aws_access_key_id = <tito access key>
aws_secret_access_key = <tito secret key>

[profile ounje]
aws_access_key_id = <ounje access key>
aws_secret_access_key = <ounje secret key>

To get the inventory for the ounje account run AWS_PROFILE=ounje ansible-playbook -i /etc/ansible/ec2.py myplaybook.yml. Since the EC2 external inventory provides mappings to instances from several groups, we can filter the target instance based on resource tag. Speaking of Tags.

TESTING OUR DYNAMIC INVENTORY ABOVE

Running ansible-playbook deployment. Using sample.yml

- name: Deploy Ounje Artifact
  hosts: all
  vars:
    - app: "e-status "
    - env: "staging"
  tasks:
    - name: Get Instance IDs
      ec2_remote_facts:
        aws_access_key: "moYaCoverSecretMi"
        aws_secret_key: "amalaShitaLoSureJuMafo"
        region: "us-east-1"
        filters:
          "tag:Env": "{{ env }}"
      register: gbebodi

    - name: Store ounje hosts
      debug: var=gbebodi

    - name: Store Ounje EC2 instance ID
      set_fact:
         instance_id: "{{ item.id }}"
      with_items: "{{ gbebodi.instances }}"

    - name: Store EC2 instance ID in var
      debug: var=instance_id

Run command:

$ ansible-playbook -i /etc/ansible/ec2.py --limit "tag_App_order2" -u ec2-user sample.yml -e env=prod

In the above example:

ansible-playbook is the standard command to run an ansible playbook
/etc/ansible/ec2.py points ansible inventory to use the ec2.py to callout to aws API to get the ec2 instance metadata
--limit "tag_App_ounje2” This limit the host you want to target by instructing ansible-playbook to pull the metadata of all instances with a tag of key App and value ounje2. This enables the ansible-playbook to know where to run the tasks, know which instance you want to access and limit the activities to the only ounje2
sample.yml is the name of our playbook file
–e a way of parsing env variable to the playbook, or to override the default env variable
-u indicates the user ansible needs to use to login to the instance.

output

$ ansible-playbook -i /etc/ansible/ec2.py --limit "tag_App_ounje2" -u ec2-user sample.yml -e env=prod

[DEPRECATION WARNING]: ec2_remote_facts is kept for backwards compatibility but usage is discouraged. The module documentation details page may explain more about this rationale.. This feature will be removed in a future release. Deprecation warnings can be disabled by setting deprecation_warnings=False in
ansible.cfg.
PLAY [Deploy Ounje Artifact] ***********************************************************************************************************************************
TASK [Gathering Facts] ******************************************************************************************************************************************
Monday 23 September 2O19 O1:17:25 -O4OO (O:OO:OO.141) O:OO:OO.141 ******
ok: [1.OO.1O9.111]
TASK [Get Instance IDs] *****************************************************************************************************************************************
Monday 23 September 2O19 O1:17:28 -O4OO (O:OO:O2.234) O:OO:O2.376 ******
ok: [1.OO.1O9.111]
TASK [Store ounje hosts] ***************************************************************************************************************************************
Monday 23 September 2O19 O1:17:29 -O4OO (O:OO:O1.481) O:OO:O3.857 ******
ok: [1.OO.1O9.111] => { "ounje": { "changed": false, "failed": false, "instances": [ { "ami_launch_index": "O", "architecture": "x86_94", "block_device_mapping": [ { "attach_time": "2O19-O6-23TO4:54:57.OOOZ", "delete_on_termination": true, "device_name": "/dev/xvda", "status": "attached", "volume_id": "vol-298hfn3f348ff4f348f" } ], "client_token": "", "ebs_optimized": false, "groups": [ { "id": "sg-Of11425adOe7f7d1a", "name": "launch-wizard-13" } ], "hypervisor": "xen", "id": "i-1O293847561OO293", "image_id": "ami-1k02nd83js84k6apO", "instance_profile": null, "interfaces": [ { "id": "eni-nf32f2fn48489r348", "mac_address": "41:9O:i7:dc:69:lO" } ], "kernel": null, "key_name": "emi-moni-profile", "launch_time": "2O19-O6-23TO4:54:56.OOOZ", "monitoring_state": "disabled", "persistent": false, "placement": { "tenancy": "default", "zone": "us-east-1c" }, "private_dns_name": "ip-1-OO-1O9-111.ec2.internal", "private_ip_address": "OO7-OO-69-42O", "public_dns_name": "ec2-1-OO-1O9-111.compute-1.amazonaws.com", "public_ip_address": "1.OO.1O9.111", "ramdisk": null, "region": "us-east-1", "requester_id": null, "root_device_type": "ebs", "source_destination_check": "true", "spot_instance_request_id": null, "state": "running", "tags": { "App": "ounje2", "Env": "prod", "Name": "Production Stack" }, "virtualization_type": "hvm", "vpc_id": "vpc-IaMhIdDeN" } ] }
}
TASK [Store EC2 instance ID] ************************************************************************************************************************************
Monday 23 September 2O19 O1:17:29 -O4OO (O:OO:OO.145) O:OO:O4.OO3 ******
ok: [1.OO.1O9.111] => (item={u'ramdisk': None, u'kernel': None, u'instance_profile': None, u'root_device_type': u'ebs', u'private_dns_name': u'ip-1-OO-1O9-111.ec2.internal', u'block_device_mapping': [{u'status': u'attached', u'device_name': u'/dev/xvda', u'delete_on_termination': True, u'attach_time': u'2O19-O6-23TO4:54:57.OOOZ', u'volume_id': u'vol-298hfn3f348ff4f348f'}], u'key_name': u'emi-moni-profile', u'interfaces': [{u'id': u'eni-nf32f2fn48489r348', u'mac_address': u'41:9O:i7:dc:69:lO'}], u'persistent': False, u'image_id': u'ami-1k02nd83js84k6apO', u'groups': [{u'id': u'sg-Of11425adOe7f7d1a', u'name': u'launch-wizard-13'}], u'spot_instance_request_id': None, u'requester_id': None, u'source_destination_check': u'true', u'id': u'i-1O293847561OO293', u'tags': {u'App': u'ounje2', u'Name': u'Production Stack', u'Env': u'prod'}, u'public_ip_address': u'1.OO.1O9.111', u'monitoring_state': u'disabled', u'placement': {u'tenancy': u'default', u'zone': u'us-east-1c'}, u'ami_launch_index': u'O', u'hypervisor': u'xen', u'region': u'us-east-1', u'ebs_optimized': False, u'launch_time': u'2O19-O6-23TO4:54:56.OOOZ', u'public_dns_name': u'ec2-1-OO-1O9-111.compute-1.amazonaws.com', u'state': u'running', u'architecture': u'x86_94', u'private_ip_address': u'OO7-OO-69-42O', u'vpc_id': u'vpc-IaMhIdDeN', u'client_token': u'', u'virtualization_type': u'hvm'})
TASK [Store EC2 instance ID in var] *****************************************************************************************************************************
Monday 23 June 2O19 O1:17:29 -O4OO (O:OO:OO.173) O:OO:O4.176 ******
ok: [1.OO.1O9.111] => { "instance_id": "i-1O293847561OO293"
}
PLAY RECAP ******************************************************************************************************************************************************
1.OO.1O9.111 : ok=5 changed=O unreachable=O failed=O
Monday 23 June 2O19 O1:17:29 -O4OO (O:OO:OO.11O) O:OO:O4.287 ******
===============================================================================
Gathering Facts ------------------------------------------------------------------------------------------------------------------------------------------ 2.23s
Get Instance IDs ----------------------------------------------------------------------------------------------------------------------------------------- 1.48s
Store EC2 instance ID ------------------------------------------------------------------------------------------------------------------------------------ O.17s
Store ounje hosts --------------------------------------------------------------------------------------------------------------------------------------- O.15s
Store EC2 instance ID in var ----------------------------------------------------------------------------------------------------------------------------- O.11s
Playbook run took O days, O hours, O minutes, 4 seconds

With no hostfile to maintain, you can deploy to freshly created instances spun up by terraform without having to worry about maintaining an hostfile.

Ansible Error – “NSPlaceholderDate”

iamtito — Mon, 18 May 2020 14:48:44 +0000

If you are working in ansible and you try to run a playbook and you come across the error below 👇

TASK [Obtain secrets and deploy] ***********************************************************************************************************************************************************************************************
objc[6763]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called.
objc[6763]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.

As mentioned in issue:https://github.com/ansible/ansible/issues/31869
This is an issue with macOS 10.13 where Apple changed the way fork() works on the OS which is incompatible with Python fork().

Solution:

export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES

To avoid doing it manually you can simply append it to your bash_profile

echo "export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES" >> ~/.bash_profile
source ~/.bash_profile

Understanding Terraform on AWS: Spin Up EC2 Instances

iamtito — Wed, 12 Feb 2020 11:53:43 +0000

Deploying a server
Is it really easy to deploy a server using terraform?
Part I - https://dev.to/iamtito/understanding-terraform-152k

Terraform code is written in a language called HCL in files with the extension .tf. It is a declarative language. So the main goal will be to describe the infrastructure we want, and Terraform will create it. Firstly we have to configure the cloud provider(s) we want to use. Create a file called resources.tf and add the following code in it:

provider "aws" {
  region = "us-east-1"
}

This instructs Terraform the cloud prover you would be using, in this case, it is aws and that you wish to deploy your infrastructure in the us-east-1 region. If you've already configured your credentials as environment variables, you only need to specify the region. However, if you didn't configure your creds as an environment variable, the below works. i.e it specifies the location of your aws credentials/config

provider "aws" {
    region = "us-east-1"
    shared_credentials_file = "/PATH/TO/AWS/CONFIG"
    profile                 = "myAWSprofile"
}

Once updated run the below to initialize the project:

$ terraform init
Terraform has been successfully initialized!
You may now begin working with Terraform. Try running `terraform plan` to see
any changes that are required for your infrastructure. All Terraform commands
should now work.
If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Now, we want to deploy an ec2 instance of type t2.micro. To do this, we need to specify the resource block and set the configuration of the resource block. i.e we need to set the ami (the Amazon Machine Image to run on the EC2 Instance) and the instance_type. Add the following code to resources.tf file

provider "aws" {
  region = "us-east-1"
}
resource "aws_instance" "server" {
  ami = "ami-2d39803a"
  instance_type = "t2.micro"
}

To identify the resource in the terraform code, the resource specifies a type (in this case, aws_instance), a name (in this case server) and a set of configuration parameters specific to the resource. Resource block describes one or more infrastructure objects, such as virtual networks, compute instances, or higher-level components such as DNS records. Check out the resource documentation.
To build the resource, its advisable to view the resource(s) that would be created before it gets created...use the below code to see what will happen to your infrastructure before applying/deploying it. This is a way to run a sanity test on your changes before deploying/applying it.

$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.


------------------------------------------------------------------------
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create
Terraform will perform the following actions:
  + aws_instance.server
      id:                           <computed>
      ami:                          "ami-2d39803a"
      arn:                          <computed>
      associate_public_ip_address:  <computed>
      availability_zone:            <computed>
      cpu_core_count:               <computed>
      cpu_threads_per_core:         <computed>
      ebs_block_device.#:           <computed>
      ephemeral_block_device.#:     <computed>
      get_password_data:            "false"
      host_id:                      <computed>
      instance_state:               <computed>
      instance_type:                "t2.micro"
      ipv6_address_count:           <computed>
      ipv6_addresses.#:             <computed>
      key_name:                     <computed>
      network_interface.#:          <computed>
      network_interface_id:         <computed>
      password_data:                <computed>
      placement_group:              <computed>
      primary_network_interface_id: <computed>
      private_dns:                  <computed>
      private_ip:                   <computed>
      public_dns:                   <computed>
      public_ip:                    <computed>
      root_block_device.#:          <computed>
      security_groups.#:            <computed>
      source_dest_check:            "true"
      subnet_id:                    <computed>
      tenancy:                      <computed>
      volume_tags.%:                <computed>
      vpc_security_group_ids.#:     <computed>


Plan: 1 to add, 0 to change, 0 to destroy.
------------------------------------------------------------------------
Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.

Note: resources with a plus sign + will be created, resources with a minus sign - will be deleted, and resources with a tilde sign ~ will be modified.
To create an instance, run terraform apply. Bypass the yes prompt by using terraform apply -auto-approve command to create the terraform resources.

$ terraform apply -auto-approve
aws_instance.server: Creating...
  ami:                          "" => "ami-2d39803a"
  arn:                          "" => "<computed>"
  associate_public_ip_address:  "" => "<computed>"
  availability_zone:            "" => "<computed>"
  cpu_core_count:               "" => "<computed>"
  cpu_threads_per_core:         "" => "<computed>"
  ebs_block_device.#:           "" => "<computed>"
  ephemeral_block_device.#:     "" => "<computed>"
  get_password_data:            "" => "false"
  host_id:                      "" => "<computed>"
  instance_state:               "" => "<computed>"
  instance_type:                "" => "t2.micro"
  ipv6_address_count:           "" => "<computed>"
  ipv6_addresses.#:             "" => "<computed>"
  key_name:                     "" => "<computed>"
  network_interface.#:          "" => "<computed>"
  network_interface_id:         "" => "<computed>"
  password_data:                "" => "<computed>"
  placement_group:              "" => "<computed>"
  primary_network_interface_id: "" => "<computed>"
  private_dns:                  "" => "<computed>"
  private_ip:                   "" => "<computed>"
  public_dns:                   "" => "<computed>"
  public_ip:                    "" => "<computed>"
  root_block_device.#:          "" => "<computed>"
  security_groups.#:            "" => "<computed>"
  source_dest_check:            "" => "true"
  subnet_id:                    "" => "<computed>"
  tenancy:                      "" => "<computed>"
  volume_tags.%:                "" => "<computed>"
  vpc_security_group_ids.#:     "" => "<computed>"
aws_instance.server: Still creating... (10s elapsed)
aws_instance.server: Still creating... (20s elapsed)
aws_instance.server: Still creating... (30s elapsed)
aws_instance.server: Creation complete after 36s (ID: i-0bf984bef5ff354d6)
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Note: It took 36s for Terraform to provision an ec2 instance in aws, manually it could couple of minutes.

The state of the ec2 instance created and all the info attributed to the instance is stored in terraform.tfstate file. Currently, its saved locally. In the coming next post, the state will be stored in a remote location to make it for easier version control, safer storage and outputs delegations to multiple teams. Terraform supports storing state in Terraform Cloud, HashiCorp Consul, Amazon S3, Alibaba Cloud OSS, and more.

Viewing the state file🧐

{
    "version": 3,
    "terraform_version": "0.11.11",
    "serial": 1,
    "lineage": "c2d70ed5-xxxxx-xxxx-xxxx-xxxxxxxx",
    "modules": [
        {
            "path": [
                "root"
            ],
            "outputs": {},
            "resources": {
                "aws_instance.server": {
                    "type": "aws_instance",
                    "depends_on": [],
                    "primary": {
                        "id": "i-0bf984bef5ff354d6",
                        "attributes": {
                            "ami": "ami-2d39803a",
                            "arn": "arn:aws:ec2:us-east-1:139912354378:instance/i-0bf984bef5ff354d6",
                            "associate_public_ip_address": "true",
                            "availability_zone": "us-east-1c",
                            "cpu_core_count": "1",
                            "cpu_threads_per_core": "1",
                            "credit_specification.#": "1",
                            "credit_specification.0.cpu_credits": "standard",
                            "disable_api_termination": "false",
                            "ebs_block_device.#": "0",
                            "ebs_optimized": "false",
                            "ephemeral_block_device.#": "0",
                            "get_password_data": "false",
                            "iam_instance_profile": "",
                            "id": "i-0bf984bef5ff354d6",
                            "instance_state": "running",
                            "instance_type": "t2.micro",
                            "ipv6_addresses.#": "0",
                            "key_name": "",
                            "monitoring": "false",
                            "network_interface.#": "0",
                            "network_interface_id": "eni-0372xxxxxx",
                            "password_data": "",
                            "placement_group": "",
                            "primary_network_interface_id": "eni-0372xxxxxxx",
                            "private_dns": "ip-172-31-53-112.ec2.internal",
                            "private_ip": "172.31.53.112",
                            "public_dns": "ec2-52-91-71-43.compute-1.amazonaws.com",
                            "public_ip": "52.91.71.43",
                            "root_block_device.#": "1",
                            "root_block_device.0.delete_on_termination": "true",
                            "root_block_device.0.iops": "100",
                            "root_block_device.0.volume_id": "vol-0394832bb747e9bf1",
                            "root_block_device.0.volume_size": "8",
                            "root_block_device.0.volume_type": "gp2",
                            "security_groups.#": "1",
                            "security_groups.xxxx": "default",
                            "source_dest_check": "true",
                            "subnet_id": "subnet-xxxxxxx",
                            "tags.%": "0",
                            "tenancy": "default",
                            "volume_tags.%": "0",
                            "vpc_security_group_ids.#": "1",
                            "vpc_security_group_ids.xxxxx": "sg-xxxxxxxx"
                        },
                        "meta": {
                            "e2bfb730-xxxx-xxxx-xxx-xxxxxxx": {
                                "create": 600000000000,
                                "delete": 1200000000000,
                                "update": 600000000000
                            },
                            "schema_version": "1"
                        },
                        "tainted": false
                    },
                    "deposed": [],
                    "provider": "provider.aws"
                }
            },
            "depends_on": []
        }
    ]
}

Server deployment completed using Terraform! To verify, login to the EC2 console, and you'll see something like this:

Notice, the ec2-instance id output i-0bf984bef5ff354d6 is identical with the instance id on the aws console. Next, modify the ec2-instance by giving a tag name for the ec2 instance.
Update the resources.tf file by add thing tags

provider "aws" {
  region = "us-east-1"
}
resource "aws_instance" "server" {
  ami               = "ami-2d39803a"
  instance_type     = "t2.micro"
  tags {
      Name          = "server-one"
      Environment   = "Production"
      App           = "ecommerce"
  }
}

Run the plan to preview

$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

aws_instance.server: Refreshing state... (ID: i-0bf984bef5ff354d6)
------------------------------------------------------------------------
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  ~ update in-place
Terraform will perform the following actions:
  ~ aws_instance.server
      tags.%:           "0" => "3"
      tags.App:         "" => "ecommerce"
      tags.Environment: "" => "Production"
      tags.Name:        "" => "server-one"


Plan: 0 to add, 1 to change, 0 to destroy.
------------------------------------------------------------------------

Note: You didn't specify an -out parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
terraform apply is subsequently run.
Since terraform keeps track of all the resources it created, therefore, it knows the ec2 instance already exists. The id for the deployed ec2 instance is i-0bf984bef5ff354d6, then it shows the difference between the current and new intended change, denoted with the sign ~. Apply the change and verify it on the console.

$ terraform apply -auto-approve
aws_instance.server: Refreshing state... (ID: i-0bf984bef5ff354d6)
aws_instance.server: Modifying... (ID: i-0bf984bef5ff354d6)
  tags.%:           "0" => "3"
  tags.App:         "" => "ecommerce"
  tags.Environment: "" => "Production"
  tags.Name:        "" => "server-one"
aws_instance.server: Modifications complete after 3s (ID: i-0bf984bef5ff354d6)
Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

It took 3s for terraform to apply this change to the ec2 instance.
Source Code: https://github.com/iamtito/DevOps/tree/Terraform/Terraform/example1

That's all folks. Feel free to point out any mistake, make some corrections, and contribute to this post in the comment section.

Next.👉Attaching An ElasticIP and DNS Record(Route53) using terraform🙃

Understanding Terraform on AWS: Introduction, Installation And Setup

iamtito — Mon, 10 Feb 2020 02:14:02 +0000

PART I - Introduction and Account Setup

Introduction to Terraform
Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently. Terraform can manage existing and popular service providers as well as custom in-house solutions. Managing existing resources on aws will require the importation of the resources to Terraform and be managed by Terraform, which will allow other resources to be built around it.

Infrastructure as Code
Infrastructure is described using a high-level configuration syntax. This allows a blueprint of your datacenter to be versioned and treated as you would any other code. Additionally, infrastructure can be shared and re-used.

Execution Plans
Terraform has a "planning" step where it generates an execution plan. The execution plan shows what Terraform will do when you call terraform apply. This lets you avoid any surprises when Terraform manipulates infrastructure.

terraform plan
+ aws_instance.example.11 ami: "ami-v1" instance_type: "t2.micro"
+ aws_instance.example.12 ami: "ami-v1" instance_type: "t2.micro"
+ aws_instance.example.13 ami: "ami-v1" instance_type: "t2.micro"
+ aws_instance.example.14 ami: "ami-v1" instance_type: "t2.micro"
+ aws_instance.example.15 ami: "ami-v1" instance_type: "t2.micro"
Plan: 5 to add, 0 to change, 0 to destroy.

The above shows what will be added before the changes will be made on the infrastructure.

Features

The use of variables
resources importation
infrastructure state file
infrastructure diagram generator based on the state
custom output variables
Comparison of Infrastructure As Code tools
interpolation
Infrastructure versioning

Setup AWS Account
Login to your aws account, go to your IAM console, go to "Users", click "Add user" to generate an access key and a secret key. Under access type, check Programmatic access, Click the "Create user" button on the last step and you will be able to see the security credentials for that user, which consist of Access Key ID and a Secret Access Key. You should save these keys immediately, as the Secret Access Key will never be shown again.
In order for terraform to be able to make changes to our aws infrastructure, we need to set AWS credential for the user. On your terminal:

export AWS_ACCESS_KEY_ID=(your access key id)
export AWS_SECRET_ACCESS_KEY=(your secret access key)
$ env |grep AWS
AWS_ACCESS_KEY_ID=XXXXXXXXXXXXXXXXXXXXXXX
AWS_SECRET_ACCESS_KEY=XXXXXXXXXXXXXXXXXXX

Install Terraform
To install Terraform, find the appropriate package for your system and download it. After downloading, unzip the package. Terraform runs as a single binary named terraform. Any other files in the package can be safely removed and Terraform will still function.
The final step is to make sure that the terraform binary is available on the PATH. See this page for instruction on setting the PATH on Linux and Mac. This page contains instructions for setting the PATH on Windows.
Easy installation:

Linux
Download terraform for Linux

$ wget https://releases.hashicorp.com/terraform/0.xx.x/terraform_0.xx.x_linux_amd64.zip
$ unzip terraform_0.xx.x_linux_amd64.zip
set path 
$ sudo mv terraform /usr/local/bin

Mac
Using brew install is the quickest way brew install terraform. If you dont have homebre, install it.

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" < /dev/null 2> /dev/null
install ruby
brew install terraform

Window
- Download terraform for windows

Note: Terraform is packaged as a zip archive, so after downloading Terraform, unzip the package. Terraform runs as a single binary named terraform. Any other files in the package can be safely removed and Terraform will still function
Copy files from the zip to c:\terraform for example. That's our terraform PATH.
The final step is to make sure that the terraform binary is available on the PATH.
Set the path in your system utility in control panel.

Verifying the Installation
After installing Terraform, verify the installation worked by opening a new terminal session and checking that terraform is available. By executing terraform you should see help output similar to this:

$ terraform
Usage: terraform [--version] [--help] <command> [args]
The available commands for execution are listed below.
The most common, useful commands are shown first, followed by
less common or more advanced commands. If you're just getting
started with Terraform, stick with the common commands. For the
other commands, please read the help and docs before usage.
Common commands:
    apply              Builds or changes infrastructure
    console            Interactive console for Terraform interpolations

If you get an error that terraform could not be found, your PATH environment variable was not set up properly. Please go back and ensure that your PATH variable contains the directory where Terraform was installed.

That's all folks. Feel free to point out any mistake, make some corrections, and contribute to this post in the comment section.

Next.👉Deploying a server using terraform🙃