SecDevOps: Protecting Terraform state file

Terraform is one of the most used tools to deploy Infrastructure as a Service or IaaS for short, but we have to manage it in a secure way.

Some developers add the terraform state file terraform.tfstate into the repository to share it among developers easily, which turns out to be a very bad idea as in the terraform state file also credentials and private keys are stored. So, if somebody could access to the repository, it will have automatically access to our infrastructure too!

Instead of storing the terraform state file locally or publicly in the repository. We should store it remotely in a secure way to be consistent with the changes we made.

Terraform supports many remote backends to store the state file remotely: AWS S3 Bucket, Google Cloud GS, artifactory, etc. So we can store it remotely to keep consistency among team members and we define later four options to store securely any sensitive data such as private keys, private IPs addresses or passwords.

To avoid any future mistake and do not upload those files into the repository, better to add terraform.tfstate and terraform.tfvars to your .gitignore file.

# Add to .gitignore
terraform.tfstate
terraform.tfvars

Also init.tf must be password safe.

We have several options for passing safely variables to terraform containing the passwords and private keys.

Option 1: We can use environment variables to pass values, although keep in mind that can be stored in your .bash_history file.

export TF_VAR_token="abcdefgihjklmnpq"

Option 2: Use an encrypted local file with terraform variables
Option 3: Use Hashicorp Vault
Option 4: Store it in Mac OS Keychain

Be aware to store the artifactory password also in the secrets manager!

Summing up… deploy fast but don’t forget to stay safe 🙂

How to deploy Docker images on Google Cloud Run

We can easily run dockerized apps on Google Cloud using still beta Google Cloud Run.

One thing to keep in mind is to specify $PORT variable inside our Dockerfile, by default Cloud Run always uses PORT 8080, but for portability reasons we will specify it as a variable:

# Dockerfile for Google Cloud Run
FROM php:apache
ARG PORT
ENV PORT=${PORT:-8080}
COPY . /var/www/html/
RUN sed -i 's/80/8080/g' /etc/apache2/sites-available/000-default.conf /etc/apache2/ports.conf
RUN mv "$PHP_INI_DIR/php.ini-development" "$PHP_INI_DIR/php.ini"
RUN service apache2 restart
EXPOSE $PORT

So we can deploy and run the docker locally in this way:

$ docker build --tag user/image .
$ PORT=8080 && docker run -e PORT=${PORT} --rm -p 8080:${PORT} -it user/image

Once inside a directory with the Dockerfile and the application just run:

$ gcloud projects create new-project-$RANDOM
$ gcloud config set project $PROJECT_ID
$ gcloud builds submit --tag gcr.io/$PROJECT_ID/image .
$ gcloud config set run/region us-central1
$ gcloud beta run deploy --image gcr.io/$PROJECT_ID/image --platform managed

It takes some minutes but finally gets deployed and dumps where it was deployed, something like https://$IMAGE-xxxxxxxxxx-$ZONE.run.app

Simple and vulnerable NodeJS app prone to Cross-Site Scripting (XSS) deployment with Google Cloud App Engine

I wrote a little script in node.js for a hands-on lab to test Cross-Site Scriptings (XSS).

You can download it from my github: https://github.com/spinfoo/nodexss

To deploy in Google Cloud App Engine:

$ git clone https://github.com/spinfoo/nodexss.git
$ gcloud init
$ gcloud projects create xss-lab$RANDOM
$ gcloud config set project xss-lab$RANDOM
$ gcloud projects describe xss-lab$RANDOM
$ gcloud app create --project=xss-lab$RANDOM
$ gcloud app deploy
$ gcloud app logs tail -s default