DEV Community: Paul

Blue Team Conference

Paul — Fri, 16 Sep 2022 18:27:40 +0000

Hey all! It's been a minute, to say the least. As I took on a new role as a Cloud security engineer during the pandemic, was such a blessing to have this opportunity!!!

Ok....ok...ok. Enough of me

I like to start by bridging the stop gaps between software developers/software engineers and cybersecurity practitioners. Believe in living in a world where teams, departments, groups, and divisions can all co-exist.

This is what Blue Team Conference in Chicago, IL is all about. What happens weeks before Blue Team Conference?? Well, there's a hacker summer camp in Las Vegas, both DefCon and BlackHat conventions. Defcon is going on 30+ years in the making. Wow!! and I haven't may a trip to one yet (looking to next year possible) Defcon is for the techy geek.
Blackhat has been around for the same amount of time but mainly for a businesses. If you want more information listen to the podcast CISO tradecraft as G Mark Hardy is a well-known individual and shares his experience.

BlueTeam Conference was hosted about a year ago and the community is great. I attended last week's BTC, the community was friendly. (Side note: this is my first security conference) Vendors were well knowledgeable than your usual sale representative, I mean wow these guys at Trimarc and SentinelOne, knew the company inside and out.
Now I wasn't able to make all the speakers but the lineup was great, anywhere from becoming the threat to how to make a CTF. The combination of the speaker lineup was a mix of business solutions consists of team leadership and developing a relationship, collaborating with other teams, and helping them to solve their day-to-day problems, how to hack the board, to cybersec optimizing best practices with working with metrics, logging, auditing, threat response, cloud security best practices, how to abstract cybersec metrics to convey those security measures to leadership and board members.

So what have I learned from attending Blue Team Conference (BTC). Well for starters, Trimarc had hosted their CTF and BTC also had a CTF village. There's hack4kids village where kids of all ages can learn hardware hacking to software hacking. Also, for parents, there's optional daycare for kids too.

Amazing talks about how to convey alerts, metrics, and the decrease of vulnerabilities, reporting graphs to directors, leaderships. Collab with other team members and building a working relationship and giving them a helping hand which gives you a view of their world. Building security fortress by implementing a security zero trust model with security best practices.

Most importantly is about networking and meeting new people. By striking up a conversation I meet some awesome people and I'm looking forward to next year and the continuation of BTC!!!

You can head here to BTC schedule

My Top playlist to listen to while working

Paul — Wed, 26 May 2021 15:47:42 +0000

In this post, I have curated my top playlist to listen to no matter what I'm doing. Some project, work, etc. I have list that range from all over the place and like to share for those searching for new music. Some are instrumental and some have lyrics. Please share other resources in the comments!

So I have discovered Code Focus playlist on Spotify. Ones I have picked that I like are below

spotify

YOUTUBE (at this time you can not add youtube playlist)

https://youtube.com/playlist?list=PLX5issW1RvEQ7VRinbkhvkwBPSZA5BvFR

https://youtube.com/playlist?list=PLhXK2sumhMUfqyXPPxOHLDcrb5ooeIXyF

another good channel is Mind Amend and has pretty cool graphic videos

Twitch

I usually go with music live

Automate Terraform CLI

Paul — Wed, 03 Mar 2021 17:55:09 +0000

TL:DR
If you want to know more about the mechanisms at hand, head DOWNLOAD > TerraformCLI and CHECKSUM > Terraformchksm
First, create the PGP key and name it hashicorp.asc and save it in the same directory as the Terraform CLI will be installed at. (Click CHECKSUM https://www.hashicorp.com/security to copy the PGP key)
Second, I stored the Terraform CLI in the dir that I'm working in, save it at /usr/bin if you're using macOS or Linux.
To start the script, I have created three arguments that will simplify the version and the file version that Hashicorp keeps updating. (for good reasons, I assume the developers want more features in Terraform I'm all for that)

#!/bin/bash
# Update Terraform version bash script automation
#Arguments
version=$1 #version# 0.2.28
tfver=$2 # terraform_0_2_28_darwin_amd64.zip
tfsha=$3 # terraform_0.2.28_SHA256SUMS
tfshasig=$4 #terraform_0.2.28_SHA256SUMS.sig
cd $HOME/Path/to/TerraformCLI
wget https://releases.hashicorp.com/terraform/$version/$tfver
gpg  --import hashicorp.asc
curl -Os https://releases.hashicorp.com/terraform/$version/$tfsha
curl -Os https://releases.hashicorp.com/terraform/$version/$tfshasig
gpg  --verify $tfshasig $tfsha
shasum -a 256 -c $tfsha
unzip $tfver
rm $tfver

The above image is showing four variables version number, file with version, SHA256SUMS with version, and SHA256SUMS.sig with version.
Copy and paste the bash script and chmod +x automateTFCLI.sh, then execute the script with this command
./automateTFCLI.sh 0.12.28 terraform_0.12.28_darwin_amd64.zip terraform_0.12.28_SHA256SUMS terraform_0.12.28_SHA256SUMS.sig
The script takes care of downloading, checking the integrity of the file and then, unzipping and deleting.
Leaving the Terraform CLI inflation (meaning in use)
Next run Terraform - version to output version and confirm you have the working Terraform.
(side note, I was tired of typing long cli commands so I put an alias in bash_profile to shorten it i.e alias tf="terraform" and also
tfplan="terraform init && terraform plan")

Hashicorp Terraform has made this much simpler by adding Terraform CLI from the repo using APT. SetupTFCLIAPT

If you found this article to be useful please consider buying me a cup of coffee

TerraForm IaC on Google Cloud Platform provisioning CloudRun and CloudEndpoints

Paul — Mon, 28 Sep 2020 06:06:40 +0000

Side note: I'm an intermediate Sys admin and have been building my skills to be proficient. If there's a mistake, please let me know.

Warning: Using Terraform v0.13

What is cloud run? Cloud run is a fully self-service managed infrastructure that is capable of automated scaling.
cloudrun
What is TerraForm? Terraform is a multi-cloud infrastructure as code that is open-source. This eliminates human error and reduces time.
TerraForm
In this how-to article, I'll show you how to deploy your own API on Cloud Endpoints and use the cloud run service for both Application and API gateway ESPv2 image with Terraform and cloud build.
I followed this tutorial and replicated it through CI/CD pipeline GettingStarted CloudEndpoints

Prerequisites

Create Google Cloud Project and account GCPProject
Create Github Account and new repository on Github
Enable Cloud Build app in Github Repo. and create cloud build triggers CloudbuildTr
Create Cloud run GO application, simple hello world CloudrunApp
Enable Google container registry GCR

Let's start with CI/CD pipeline through, my environment has TerraForm in version control (GitHub) with Cloud build triggers app on Github and on Google Cloud Platform.

I have another write-up. For senior or advance practitioners move to here

Configuring terraform and google cloud platform will be up to you to decide what is best for your environment but I would highly recommend best practices for both TerraForm and GCP with security in mind. Securing Cloud Run services HERE Also, permissions are important and necessary in order to deploy TerraForm configuration for use of least privilege permissions. I like to keep TerraForm DRY with reusable infrastructure as code so that I can reuse modules. Another key part in this is the template version which I have set to version = "2.1.2".
I have Cloud Build Triggers app within GitHub repo for dev, staging, and prod. This will create changes that I have made using "VScode" and commit to Github. Cloud Build triggers will be notified by branch name of the commit and running either dockerfile, cloudbuild.yaml.
Cloudbuild.yaml configs, I've set the build time to 7200s just to make sure cloud build gives ample time to finish deploying TerraForm configuration. I grab these simple and customizable steps from this tutorial HERE Basic fundamentals of using TerraForm and GCP Cloud Build.
Versions used in this tutorial
~Google provider 3.35.0
~TerraForm v.0.13.0
Once everything is configured, let's start deploying some TerraForm GCP resources

Let's Start

Start by creating a dev folder structure. Here's what's going on, backend.tf is saving remote state to cloud storage bucket. Steps to setup remote state is in the above tutorial, Managing Infrastructure as code. Main.tf is Terraform root dir config, which holds the modules and google provider. Outputs.tf file will pass the output URL from the cloud run modules. Versions.tf is important to keep every TerraForm in sync.

├── README.md
├── cloudbuild.yaml
├── gcloud_build_image
├── environments
│ └── dev
│ ├── backend.tf
│ ├── main.tf
│ ├── outputs.tf
│ └── versions.tf
│ ├── staging
│ ├── prod
├── modules
│ └── services
│ ├── CloudRun
│ │ ├── cloudrun.tf
│ │ ├── outputs.tf
│ │ └── variables.tf
│ ├── cloudEndpoints
│ │ ├── endpoints.tf
│ │ ├── openapi_spec.yml
│ │ └── variables.tf

In the Root dir. we have cloudbuild.yaml and gcloud_build_image, also do a readme.md to explain what the repo and how-to so that other team members can get started.
We have modules/services/ TerraForm resources configurations of cloud run and cloud endpoints. For the sake of this tutorial, I have used hello world with a simple cloud endpoint that are used for the hello GO app. You may need to check configuration for security and if needed use CORS and set IAM permission to the cloud run services.

Moving on to the cloud run module configs I will start with cloud run services. Here we will use the default of cloud run with IAM policy "no-auth" and created variables for the name, location, and a docker image.

# ------------------------------------------------------------------------------
# GCP cloud run application 
# ------------------------------------------------------------------------------

resource "google_cloud_run_service" "default" {
  name     = var.name
  location = var.location
  template {
    spec {
      containers {
        image = var.dockerimg 
      }
    }

  }
  
  traffic {
    percent         = 100
    latest_revision = true
  }
  autogenerate_revision_name = true
}
data "google_iam_policy" "noauth" {
  binding {
    role = "roles/run.invoker"
    members = [ 
      "allUsers",
  ]
 }
}
resource "google_cloud_run_service_iam_policy" "noauth" {
  location = google_cloud_run_service.default.location
  project  = google_cloud_run_service.default.project
  service  = google_cloud_run_service.default.name
  policy_data = data.google_iam_policy.noauth.policy_data
}

# ------------------------------------------------------------------------------
#  variables for Cloud Run                                                              
# ------------------------------------------------------------------------------
variable "name" {
    description = "variable name for cloud run" 
    type = string 
}
variable "location" {
    description = "setting location of service"
    default = "us-central1"
}
variable "project" {
    description = " setting project name"
    type = string 
}
variable "dockerimg" {
  description = "docker img to be used"
  type = string
}

# ------------------------------------------------------------------------------
#  outputs for Cloud Run                                                              
# ------------------------------------------------------------------------------
output url {
  value = google_cloud_run_service.default.status[0].url
}
output urlesp {
  value = "${trimprefix(google_cloud_run_service.default.status[0].url, "https://")}"
}

Next, we have cloud endpoints module configs. I've used the data template file to import openapi_spec.yaml into the cloud endpoint config, I also have it in the cloud endpoint module dir. A couple of things going on here, I've created variables for data openapi.yaml config. This will pass in variables from the TerraForm root config into the cloud endpoint module.

# # ------------------------------------------------------------------------------
# # Cloud endpoints
# # ------------------------------------------------------------------------------

data "template_file" "openapi_spec" {
 template = "${file("${path.module}/openapi_spec.yml")}"
 vars = {
   CloudRunES = var.CloudRunESurl ,
   HelloAPI = var.ClRnSrvapp
 }
}

resource "google_endpoints_service" "api-service" {
  service_name   = var.CloudRunES2url
  project        = var.project
  openapi_config    = data.template_file.openapi_spec.rendered
}

 swagger: '2.0'
  info:
    title: Cloud Endpoints + Cloud Run
    description: Sample API on Cloud Endpoints with a Cloud Run backend
    version: 1.0.0
  host: ${CloudRunES}
  schemes:
    - https
  produces:
    - application/json
  x-google-backend:
    address:${HelloAPI}
    protocol: h2
  paths:
    /hello:
      get:
        summary: Greet a user
        operationId: hello
        responses:
          '200':
            description: A successful response
            schema:
              type: string

variable "project" {
  description = "name of project"
  type        = string
}
variable "CloudRunESurl" {
   type = string
}
variable "ClRnSrvapp" {
   type = string 
}

Ok so now that we have the module services configured we can jump back to the staging folder and configure the Terraform root config (main.tf)
Cloud Run ESPv2 service will be created at the same time as Cloud Run GO application.
Further guide is at this doc

# # ------------------------------------------------------------------------------
# # Terraform provider
# # --------------------------------------------------------------------------------
provider google {
    project = "Project_ID"
    region = "var.region" 
}
provider "template" {
  version = "2.1.2"
}
# ------------------------------------------------------------------------------
#  cloud run and cloud endpoints
# ------------------------------------------------------------------------------
module "HelloAPI" {
   source = "../../modules/services/CloudRun"
   name = "hellotest"
   location = "us-central1"
   project = "Project_ID"
   dockerimg = "gcr.io/${Project_ID}/cloud-run-hello:v2"
}
module "CloudApiESP" {
  source = "../../modules/services/CloudRun"
  name = "cloudrunesp"
  location = "us-central1"
  project = "Project_ID"
  dockerimg = "gcr.io/${Project_ID}/endpoints-runtime-serverless:cloudapiesp-qutnc7nuq-uc.a.run.app-2020-08-017r0"
}
# ------------------------------------------------------------------------------
#  variables for Cloud endpoints                                                       
# ------------------------------------------------------------------------------
module "cloudEndpoints" {
  
    source = "../../modules/services/cloudEndpoints"
    project = "Project_ID"
    
    CloudRunESurl = "${module.CloudApiESP.urlesp}"
    ClRnSrvapp    = "${module.HelloAPI.url}"
}

The above config is calling module services cloud run and in that module we are creating name, location, project, and inputting docker image, which is from Google Container Registry. Cloud Run only runs images from GCR. Next, in cloud endpoints module we are creating cloud endpoint and the only configuration we are doing is passing in env variables. What this means is passing the output urls from cloud run module to main config as an output and then to cloud endpoints module env. vars. This is the only way to pass environment variables to main config and then to other module service.
Finally, we're going to create the cloud build yaml config for Continuous deployment. What this does is that cloud build will run steps to create a alpine busy box per say and install Terraform and allows for cloud build to cd into the root folder and modules configurations and be provisioned and deployed. I've also typed in TF_LOG=TRACE which will display TerraForm execution in the background through the cloud build, build log.
Cloudbuild.yaml

# Copyright 2019 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     https://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
timeout: 7200s
steps:

# - name: gcr.io/cloud-builders/gcloud
#   entrypoint: 'bash'
#   args: 
#     - '-c'
#     - |-
#       chmod +x gcloud_build_image 
#       ./gcloud_build_image -s ${cloudrun-esp}-${cloudrun-hash}-uc.a.run.app -c ${config-id} -p ${project-id}
 
  
- id: 'branch name'
  name: 'alpine'
  entrypoint: 'sh'  
  args: 
  - '-c'
  - | 
      echo "***********************"
      echo "$BRANCH_NAME"
      echo "***********************"
  #[start tf-init]
- id: 'tf init'
  name: 'hashicorp/terraform:0.13.0'
  entrypoint: 'sh'
  args: 
  - '-c'
  - |
      if [ -d "environments/$BRANCH_NAME/" ]; then
        cd environments/$BRANCH_NAME
        terraform init
      else
        for dir in environments/*/
        do 
          cd ${dir}   
          env=${dir%*/}
          env=${env*/}
          echo ""
          echo "*************** TERRAFORM INIT ******************"
          echo "******* At environment: ${env} ********"
          echo "*************************************************"
          terraform init || exit 1
          cd ../../
        done
      fi 
  
# [START tf-plan]
- id: 'tf plan'
  name: 'hashicorp/terraform:0.13.0'
  entrypoint: 'sh'
  args: 
  - '-c'
  - | 
      if [ -d "environments/$BRANCH_NAME/" ]; then
        cd environments/$BRANCH_NAME
        terraform plan
        
      else
        for dir in environments/*/
        do 
          cd ${dir}   
          env=${dir%*/}
          env=${env*/}  
          echo ""
          echo "*************** TERRAFOM PLAN ******************"
          echo "******* At environment: ${env} ********"
          echo "*************************************************"
          terraform plan  || exit 1
          cd ../../
          cat crash.log 
        done
      fi 
  
 # [END tf-plan]
#[START tf-apply]
- id: 'tf apply'
  name: 'hashicorp/terraform:0.13.0'
  entrypoint: 'sh'
  args: 
  - '-c'
  - | 
      if [ -d "environments/$BRANCH_NAME/" ]; then
        cd environments/$BRANCH_NAME      
        export TF_LOG=TRACE
        terraform apply -auto-approve 
      else
        echo "***************************** SKIPPING APPLYING *******************************"
        echo "Branch '$BRANCH_NAME' does not represent an oficial environment."
        echo "*******************************************************************************"
      fi

 
 
#[START tf-destroy]
# - id: 'tf destroy'
#   name: 'hashicorp/terraform:0.13.0'
#   entrypoint: 'sh'
#   args: 
#   - '-c'
#   - | 
#       if [ -d "environments/$BRANCH_NAME/" ]; then
#         cd environments/$BRANCH_NAME      
#         export TF_LOG=TRACE
#         terraform destroy -auto-approve 
#       else
#         echo "***************************** SKIPPING APPLYING *******************************"
#         echo "Branch '$BRANCH_NAME' does not represent an oficial environment."
#         echo "*******************************************************************************"
#       fi
  #[end tf-destroy]

Once all has been configured, we can then commit to GitHub branch to deploy. We will have two Cloud Run services and one Cloud Endpoints.
Next, we will need to redeploy Cloud Run ESPv2 by rebuilding it, using the gcloud_build_image script provided at the bottom of this tutorial GcloudBuildImage

# - name: gcr.io/cloud-builders/gcloud
#   entrypoint: 'bash'
#   args: 
#     - '-c'
#     - |-
#       chmod +x gcloud_build_image 
#       ./gcloud_build_image -s ${cloudrun-esp}-${cloudrun-hash}-uc.a.run.app -c ${config-id} -p ${project-id}

We will need to copy Google Container Registry image name so that we can enter that in the Cloud Run ESPv2 Cloud Run service to be redeployed. All we need to do is copy the ESPv2 image name and paste it in the dockimg= ESPv2 image name in the Cloud Run ESPv2 module of TerrForm main.tf.
We should be able to go to the Cloud Endpoint URL is a form of Cloud Run ESPv2 URL /hello.

i.e https://${cloudapiesp-url}-CloudRun-hash.a.run.app/hello

Next, we will change some code on the Cloud Run GO application for continuous integration while rebuilding Cloud Run service. I have a separate GitHub repo. for my Cloud Run application.
Inside of that separate Cloud Run application GitHub Repo. I have a cloudbuild.yaml that is configured with Cloud Build Triggers to that GitHub repo. So everytime I make a commit, I can then run the Continous integration everytime I commit.

steps:
 -name: 'gcr.io/cloud-builders/docker'
 args: [ 'build', '-t', 'gcr.io/project_id/cloudrun-hello', '.']
-name: gcr.io/cloudbuilders/docker'
args: [ 'push', 'gcr.io/project_id/cloudrun-hello']
-name: 'gcr.io/cloud-builders/gcloud'
args:
[
 "run", 
"deploy",
"hellotest",
" - image",
"gcr.io/project_id/cloudrun-hello",
" - region",
"us-central1",
" - platform",
"managed",
" - allow-unauthenticated",
]

You could also build the Cloud Run hello application with a new tag then, update the cloud run on the TerraForm config to deploy with the new tag. Cloud Run is not aware of any application update and doesn't automatically pull the latest image from GCR. In the above gcloud cloud build config, you can run a build of docker container image with the new tag
i.e

args: [ 'build', '-t', 'gcr.io/project_id/cloudrun-hello:v2', '.']

Instead of running the docker push command and gcloud deploy command.
Eliminating overhead and complexity.

Then, head back to the module HelloAPI and change the docker image to the version that you set above in the cloudbuild step config.

Let me know of feedback

Automate start and stop of Google Cloud Compute Engine

Paul — Sat, 11 Jul 2020 18:03:27 +0000

Photo by Luca Bravo on Unsplash

Start and stop Google Compute Engine for developing (keeps cost and resources down)

This script will start/stop Google Compute Engine vm instance, script starts a vm instance for anyone to use and test in a dev environment.
Once task are done simply exit out of ssh and the script will automatically turn off the vm instances.

You will need the GCLOUDSDK and setup ssh keys or os login for the vm instance.

Download to dir and chmod +x startopvm.sh (or whatever name you want to call it) and then enter the input of which vm instances you are using

./startopvm.sh project_name vm_instance zone

#! /bin/bash

gcloud info 

gcloud projects list

# arguments

Project=$1   #project id that you'll be working on 

vminsta=$2  #vm instances name that you are starting within that project id 

zone=$3    # zone of vm instance that is running in, this format will be in i.e  --zone=us-central1-a 

gcloud config set project $Project 

gcloud compute instances list 


gcloud compute instances start $vminsta $zone

gcloud compute ssh $vminsta $zone



# An error exit function

error_exit()
{
    echo "$1" 1>&2
    exit 1
}

# Using error_exit

if gcloud compute instances list --filter="status=running"; then

  echo "Instance name: $instances"

else
    error_exit "Cannot start!  Aborting."
fi 
  if echo "logout"; then 
  gcloud compute instances stop $vminsta $zone 

  echo "gcloud compute instances stopping"  

else

  error_exit "cannot stop" 
fi

When you're done developing or testing simply enter exit in the ssh vm instance and the script will shutdown the vm instance.

Deploy RoR on GAE and Codeship CI/CD pipeline

Paul — Fri, 19 Jul 2019 19:21:31 +0000

A continuous integration and continuous deployment to Google App Engine with Ruby on Rails

I have the time to gain knowledge in deploying a Ruby on Rails app to Google Cloud Platform. Creating a CI/CD pipeline with CloudBees Codeship to Google App Engine (GAE). GAE is a very simplistic way of deploying services that. More information on GAE can be found here. GAE Docs
GAE is very easy to do a blue/green canary upgrade and many other features. There's quite a bit of working gears per say in this deployment but once done, any changes to the code will be simplistically. Only down side I have to this is that the cloudbuild takes forever to build and if you had to change one line of code, you'll be waiting for at least two hours.

To start we select GAE app engine flex. I ended up building my own Ruby image through Docker and pushed it to GCR (Google Container Registry). The current app engine flex was not compatible with our version of RoR. Other, services included GCP Sql (postgres) and GCP memorystore (redis).
I also added sidekiq to create an instance to connect with cloud sql.(detailed below)

cloudsql sidekiq
beta_settings:
  cloud_sql_instances: GCP_Project_ID:us-central1:Name_CloudSql

network:
  name: default

skip_files:
  - .env
  - .bundle
  - .byebug_history
  - .vscode/
  - .idea/
  - storage/
  - vendor/
  - log/
  - tmp/

I use CloudBees Codeship services for a secure CI/CD pipeline and GCP KMS to encrypt credentials.

With deploying to GAE you will need to add Dockerfile which is then built on cloudbuild. Let's get into the trenches and build something cool.
(examples only)

FROM gcr.io/GCP_Project_Name/Name_of_Image

EXPOSE 8080
ARG ruby_version=2.5.3
ARG bundler_version=1.17.1

# Ruby
ENV DEFAULT_RUBY_VERSION=${ruby_version}

# Install Ruby, set default Ruby version, and install Bundler
RUN rbenv global 2.5.3

# Workdir
ADD . /workspace/
WORKDIR /workspace/

# CloudSQL
VOLUME /cloudsql

# Set up environment variables used in production
ENV RACK_ENV=production \
RAILS_ENV=production \
RAILS_SERVE_STATIC_FILES=true

# Run bundle
RUN gem install bundler 
RUN rbenv exec gem install bundler
RUN bundle install --deployment --without="development test"

#ARG for authentication docker image 
ARG DB_PASS
ARG SECRET_B_KEY 


#env-variable for app-beta.yaml and worker-beta.yaml
ENV SECRET_KEY_BASE=${SECRET_B_KEY}
ENV RAILS_ENV="production"
ENV RACK_ENV="production"
ENV SERVICE_NAME="authentication"
ENV REDIS_HOST="10.0.0.3"
ENV REDIS_PORT=6379
ENV DATABASE_USER="postgres"
ENV DATABASE_PASS=${DB_PASS}
ENV DATABASE_NAME="postgres"
ENV DATABASE_HOST="/cloudsql/GCP-project:us-central1:nameofdb"
 ENV RAILS_LOG_TO_STDOUT: enabled
 ENV RAILS_SERVE_STATIC_FILES: enabled
 ENV LANG: en_US.UTF-8

# Entrypoint
CMD bundle exec puma -p 8080 -e production && bundle exec sidekiq -t 120 -C config/sidekiq.yml

As you can see the ENV-Var are not what you expect. This is because I have encrypted them until they reach GAE where GCP KMS decrypts them automatically (More on this later)

Creating own docker ruby image and pushing to Google Container Registery

 # Use the base image provided by Google
FROM gcr.io/gcp-runtimes/ruby/ubuntu16

# Ruby 2.4.5
ARG ruby_version=2.4.5
ARG bundler_version=1.17.1
RUN rbenv install -s ${ruby_version} \
    && rbenv global ${ruby_version} \
    && rbenv rehash \
    && (bundle version > /dev/null 2>&1 \
        || gem install bundler --version ${bundler_version}) \
    && rbenv rehash && gem cleanup

# Ruby 2.5.3
ARG ruby_version=2.5.3
ARG bundler_version=1.17.1
RUN rbenv install -s ${ruby_version} \
    && rbenv global ${ruby_version} \
    && rbenv rehash \
    && (bundle version > /dev/null 2>&1 \
        || gem install bundler --version ${bundler_version}) \
    && rbenv rehash && gem cleanup

# Ruby 2.6.1
ARG ruby_version=2.6.1
ARG bundler_version=2.0.1
RUN rbenv install -s ${ruby_version} \
    && rbenv global ${ruby_version} \
    && rbenv rehash \
    && (bundle version > /dev/null 2>&1 \
        || gem install bundler --version ${bundler_version}) \
    && rbenv rehash && gem cleanup

# ENV
ENV DEFAULT_RUBY_VERSION=${ruby_version}

I also wanted to point out cloudsql is proxied already within sidekiq
add the configuration within -config -database.yml and in the Dockerfile ENV DATABASE_HOST=.

Now moving on to CloudBees CODESHIP

CloudBees Codeship has a very simple and secure way for CI/CD pipeline. In order to do this you can get a free service or paid service. In the example below is by a pro subscription. CloudBees Codeship GCP
my examples

We need to authenticate CloudBees Codeship to GCP
this will be done by going to projects and then projects setting and getting an aes key so that jet cli (which is run on docker) to encrypt the env_var of GCP project credentials.

Create service and steps for CloudBees Codeship to execute to GCP
Codeship GCP service should look something like this

googleclouddeployment:
  image: codeship/google-cloud-deployment
  encrypted_env_file: env_e.encrypted
  add_docker: true
  working_dir: /google-deploy.sh
  volumes:
    - ./:/deploy

though depending if you are deploying on more than one GCP service such as GKE, then the service will be more detailed.

Codeship GCP steps should look something like this

- name: google-cloud-deployment
  service: googleclouddeployment
  command: bash /deploy/google-deploy.sh

and finally Codeship GCP google-deploy.sh


#!/bin/bash
set -e
# Authenticate with the Google Services
codeship_google authenticate
echo "Setting default project $GOOGLE_PROJECT_ID"
gcloud config set project *Project_name

# switch to the directory containing your app.yml (or similar) configuration file
# note that your repository is mounted as a volume to the /deploy directory
cd /deploy/
# deploy the application
gcloud builds submit --config cloudbuild.yaml --verbosity debug

CloudBuild.yaml which is doing to build the docker and push to GAE

steps:
# Build the Docker image.
- name: 'gcr.io/cloud-builders/docker'
  entrypoint: 'bash'
  args: [ '-c','docker build -t gcr.io/$PROJECT_ID/_service_:latest --build-arg DB_PASS=$$DATABASE_PASS --build-arg SECRET_B_KEY=$$SECRET_KEY
.']
  secretEnv: [ 'DATABASE_PASS', 'SECRET_KEY']

# Build Docker authentication-worker image 
- name: 'gcr.io/cloud-builders/docker'
  entrypoint: 'bash'
 gcr.io/$PROJECT_ID/appengine/_Service_:latest --build-arg DB_PASS=$$DATABASE_PASS --build-arg SECRET_B_KEY=$$SECRET_KEY --build-arg  .']

  args: [ '-c','docker build -t gcr.io/$PROJECT_ID/_Service_:latest --build-arg DB_PASS=$$DATABASE_PASS --build-arg SECRET_B_KEY=$$SECRET_KEY --build-arg  .']
  secretEnv: [ 'DATABASE_PASS', 'SECRET_KEY']

  # Push it to GCR.
- name: 'gcr.io/cloud-builders/docker'
  args: ['push', 'gcr.io/$PROJECT_ID/_Service_']   

- name: 'gcr.io/cloud-builders/docker'
  args: ['push', 'gcr.io/$PROJECT_ID/_Service_']  

# build to google app engine 
- name: 'gcr.io/cloud-builders/gcloud'
  args: ['app', 'deploy', 'app.yaml', '--image-url=gcr.io/$PROJECT_ID/_Service_']


- name: 'gcr.io/cloud-builders/gcloud'
  args: ['app', 'deploy', 'worker.yaml', '--image-url=gcr.io/$PROJECT_ID/_Service_']
timeout: 1600s


#KMS secrets 
secrets:             
- kmsKeyName:  projects/_Project-name_/locations/global/keyRings/KR_NAME/cryptoKeys/CK_name
  secretEnv:
      DATABASE_PASS: KMS encyption base_64
      SECRET_KEY: KMS encyption base_64

A lot is going on here but I want to point out that the KMS is decrypted as soon as it hits GCP network, so simple for automation.

The way I automated this was creating a script to convert this from plain text to encrypted.

#!/bin/bash


gcloud kms encrypt --plaintext-file=filename.txt --ciphertext-file=filename.enc.txt --location=global --keyring=KR_Name --key=CK_Name

base64 filename.enc.txt -i 0 > filename.enc64.txt

(this is for macos bash terminal, the base64 will be different for other os. Also, gcloud sdk was installed)

Here is the file structure