In today’s digital landscape, managing identity at scale is both a technical imperative and a strategic business enabler. Enterprises need to balance security, performance, cost-efficiency, and user experience across increasingly complex environments.

This post introduces a Keycloak Dual Deployment Strategy—a hybrid architecture that combines the control of open-source with the scalability of serverless. By segregating administrative and client-facing responsibilities across two dedicated Keycloak instances, and integrating with Oracle Cloud Infrastructure’s Autonomous Transaction Processing (OCI ATP) database, organizations can achieve robust identity management that enhances their security posture, accelerates developer productivity, and reduces operational costs.

This month, we’ve made significant strides in our identity management infrastructure by implementing this dual Keycloak deployment model. The two Keycloak instances are deployed on Google Cloud Run, enabling us to run containerized workloads with automatic scaling and minimal overhead. These instances connect securely to our existing OCI ATP database, allowing us to leverage our enterprise-grade relational data layer without migrating critical assets. Building on our previous work with Vault Server, Vault Agent, and the sidecar deployment pattern, this approach delivers both technical robustness and tangible business outcomes.

The infrastructure is fully automated using Terraform and orchestrated via Terraform Cloud, ensuring consistency, traceability, and team collaboration. The diagram below illustrates the overall architecture of this dual deployment model:

Our Dual Architecture Approach

We have designed and implemented a carefully segregated Keycloak environment consisting of:

1. Internal Administrative Instance - Providing full management capabilities to authorized internal users

2. External Client-Facing Instance - Delivering streamlined authentication services to end users

Both instances connect to the same OCI ATP database, ensuring data consistency while maintaining strict separation of access privileges.

# Our Keycloak architecture connects two distinct instances to a shared database
Internal Users → Keycloak Admin Instance → OCI ATP Database ← Keycloak External Instance ← End Users

Effortless Scalability with External Load Balancer

One of the hidden superpowers of our Keycloak dual deployment architecture lies in how seamlessly it scales — or doesn’t — depending on real-time needs.

By placing our Keycloak instances behind an external load balancer, we’ve unlocked a flexible, cloud-neutral way to manage traffic, resilience, and cost.

Scale When You Need It, Save When You Don’t

• On-demand scaling: Whether it’s 10 users or 10,000, our client-facing Keycloak instance can auto-scale based on traffic without requiring manual intervention.

• Idle = zero cost: Thanks to our Cloud Run-based serverless deployment, Keycloak services scale down to zero during off-peak hours — a huge cost-saving advantage.

Load Balancer = High Availability & Security

• The load balancer acts as a smart gatekeeper, routing requests only to healthy instances.

• We’ve enabled health checks, TLS termination, and layer-7 routing, ensuring both resilience and security at the edge.

• Compatible with advanced features like Web Application Firewalls (WAF), Geo-routing, and DDoS protection.

Cloud Agnostic by Design

• This approach works with Google Cloud Load Balancer, OCI Load Balancer, AWS ALB, or even self-managed solutions like HAProxy or NGINX.

• Our architecture avoids vendor lock-in while delivering enterprise-grade availability and performance.

Whether you’re running on Google Cloud, Oracle, AWS, or on-premises — scaling your identity platform up or down becomes a matter of toggling replicas behind your load balancer.

Why We Chose Keycloak for Enterprise Identity

When evaluating identity solutions, Keycloak emerged as the clear choice for several compelling reasons:

1. Enterprise-Grade at Open Source Cost: We gain capabilities comparable to commercial solutions like Okta and Ping Identity without the per-user licensing fees that can run into millions annually for large organizations.

2. Standards Compliance: Full implementation of OAuth 2.0, OpenID Connect, and SAML 2.0 ensures we maintain compatibility with both existing systems and future integrations.

3. Deployment Flexibility: Unlike SaaS-only options, Keycloak gives us complete control over our deployment architecture, security configurations, and data residency.

4. Proven Enterprise Adoption: Companies like Salesforce, BMW, and Deutsche Telekom have validated Keycloak's enterprise readiness, giving us confidence in our selection.

5. Vibrant Ecosystem: Regular updates, security patches, and an engaged community ensure the platform evolves alongside emerging threats and requirements.

Technical Foundation

Container Customization

Our deployment leverages custom Docker images built specifically for connection to OCI ATP:

FROM quay.io/keycloak/keycloak:<VERSION>

# Oracle connectivity components
COPY --chown=keycloak:keycloak <LIBS_PATH>/ojdbc11.jar /opt/keycloak/providers/ojdbc11.jar
COPY --chown=keycloak:keycloak <LIBS_PATH>/orai18n.jar /opt/keycloak/providers/orai18n.jar

# Wallet configuration for secure ATP connectivity
COPY --chown=keycloak:keycloak <ATP_WALLET_LOCAL_PATH> /opt/keycloak/<ATP_WALLET_LOCAL_PATH>
RUN chmod -R 750 /opt/keycloak/<ATP_WALLET_LOCAL_PATH>

# Environment configuration
ENV TNS_ADMIN=/opt/keycloak/<ATP_WALLET_LOCAL_PATH>
ENV KC_DB_DRIVER=oracle.jdbc.OracleDriver
ENV KC_DB=oracle

Feature-Based Security Separation

We've implemented security through deliberate feature control:

# External-facing instance feature configuration
features=account,account-api,login,passkeys,persistent-user-sessions,recovery-codes,web-authn,token-exchange,authorization,par,step-up-authentication,client-policies

# Explicitly disabled administrative features
features-disabled=admin,admin-api,admin-fine-grained-authz,update-email

Cloud Run Deployment Optimization

Our Cloud Run configuration optimizes for both security and performance:

# Internal Admin Instance
gcloud run deploy auth-int \
  --image "${PROJECT_LOCATION}-docker.pkg.dev/${PROJECT_ID}/${GCP_ARTIFACT_REGISTRY_NAME}/${DOCKER_IMAGE}:${NEXT_VERSION}" \
  --no-allow-unauthenticated \
  --memory=1024Mi \
  --cpu 1 \
  --min-instances=0 \
  --max-instances=1 \
  --service-account=keycloak-admin-sa@${PROJECT_ID}.iam.gserviceaccount.com

# External Client Instance
gcloud run deploy auth-ext \
  --image "${PROJECT_LOCATION}-docker.pkg.dev/${PROJECT_ID}/${GCP_ARTIFACT_REGISTRY_NAME}/${DOCKER_IMAGE}:${NEXT_VERSION}" \
  --allow-unauthenticated \
  --memory=2048Mi \
  --cpu 2 \
  --min-instances=0 \
  --max-instances=3 \
  --service-account=keycloak-client-sa@${PROJECT_ID}.iam.gserviceaccount.com \
  --cpu-boost

Performance Tuning and Optimization

The difference between a functioning system and a production-grade solution often lies in the details of configuration and tuning. We've meticulously calibrated our Keycloak deployment for optimal performance, reliability, and security:

Database Connection Pool Configuration

db-pool-initial-size=5
db-pool-min-size=5
db-pool-max-size=20
db-url-properties=maxStatements=0
db-url-properties=queryTimeout=300
db-url-properties=oracle.net.CONNECT_TIMEOUT=60000
db-url-properties=oracle.jdbc.ReadTimeout=120000

These database connection settings represent a careful balance between resource efficiency and performance. The initial and minimum pool size of 5 connections ensures immediate availability without unnecessarily consuming resources during quiet periods. The maximum pool of 20 connections allows the system to handle traffic spikes effectively.

The Oracle-specific timeout parameters address one of the most common challenges in cloud environments: network latency and temporary connectivity issues. With a connect timeout of 60 seconds and read timeout of 120 seconds, we prevent premature connection failures while ensuring the system can recover from genuine connection problems.

Security and Protocol Settings

spi-connections-http-client-default-max-connections=16
spi-connections-http-client-default-time-to-live=30
spi-connections-http-client-default-disable-trust-manager=false
spi-login-protocol-openid-connect-code-lifespan=120
spi-login-protocol-openid-connect-access-token-lifespan=300
spi-login-protocol-openid-connect-refresh-token-lifespan=1800

Our token lifespan settings strike a balance between security and user experience:

• Authorization codes valid for 2 minutes provide sufficient time for authentication flows while limiting the window for code interception

• Access tokens with a 5-minute lifespan reduce token exchange frequency during active sessions

• Refresh tokens valid for 30 minutes enable reasonable session persistence without excessive security exposure

These settings were determined after analyzing our usage patterns and security requirements, ensuring we maintain NIST-compliant security practices without unnecessary user friction.

Optimizing Performance Through Caching

theme-static-max-age=86400
theme-cache-themes=true
theme-cache-templates=true
spi-theme-cache-themes=true
spi-theme-cache-templates=true

By enabling aggressive theme and template caching with a 24-hour static resource cache, we've significantly reduced unnecessary processing and improved response times. In serverless environments, these optimizations are particularly important for reducing cold start impacts. Our performance testing showed a 42% improvement in initial page load times after implementing these caching strategies.

Infrastructure as Code Implementation

Our entire infrastructure is managed through Terraform, enabling consistent deployment across environments and reducing configuration drift. Here's a look at our key infrastructure components:

Oracle Cloud Infrastructure Resources

resource "oci_database_autonomous_database" "adb" {
  admin_password           = var.password
  compartment_id           = var.compartment_ocid
  db_name                  = var.db_name
  display_name             = var.db_name
  db_workload              = var.db_workload
  is_free_tier             = var.is_free_tier
}

resource "oci_core_network_security_group" "nsg" {
  compartment_id = var.compartment_ocid
  vcn_id         = var.vcn_id
  display_name = var.nsg_display_name
}

resource "oci_core_vcn" "vcn" {
  dns_label      = var.dns_label
  cidr_block     = var.cidr_block
  compartment_id = var.compartment_ocid
  display_name   = var.display_name
}

resource "oci_core_subnet" "subnet" {
  cidr_block        = var.cidr_block
  display_name      = var.display_name
  compartment_id    = var.compartment_ocid
  vcn_id            = var.vcn_id
  route_table_id    = var.route_table_id
  security_list_ids = var.security_list_ids
  dhcp_options_id   = var.dhcp_options_id
  dns_label         = var.dns_label
  prohibit_public_ip_on_vnic = var.prohibit_public_ip_on_vnic
  availability_domain = var.availability_domain
}

resource "oci_identity_compartment" "compartment" {
  compartment_id = var.tenancy_ocid
  description = var.description
  name = var.name
  enable_delete = var.enable_delete
}

Google Cloud Platform Resources

resource "google_artifact_registry_repository" "artifact-registry-repo" {
  location      = var.repository_location
  repository_id = var.repository_id
  description   = var.repository_description
  format        = var.repository_format
  project = var.project_id
}

resource "google_cloud_run_v2_service" "cloud_run_service" {
  name     = var.name
  location = var.gcp_region
  launch_stage = var.launch_stage
  ingress = var.ingress
  deletion_protection = var.deletion_protection
  project = var.project

  template {
    service_account = var.service_account_name
    scaling {
      max_instance_count = var.maxScale
      min_instance_count = var.minScale
    }
    containers {
      image = var.image
      resources {
        limits = {
          cpu = var.cpu
          memory = var.memory
        }
        cpu_idle = true
        startup_cpu_boost = true
      }

      # Handle regular environment variables
      dynamic "env" {
        for_each = var.environment_variables
        content {
          name  = env.value.name
          value = env.value.value
        }
      }

      # Handle secret environment variables
      dynamic "env" {
        for_each = var.secret_environment_variables
        content {
          name = env.value.name
          value_source {
            secret_key_ref {
              secret  = env.value.secret_id
              version = env.value.version
            }
          }
        }
      }
    }
  }
  lifecycle {
    ignore_changes = [
      # Ignore changes to specific attributes, e.g., image or environment variables
      template[0].containers[0].image,
      template[0].containers[0].env,
      template[0].volumes,
    ]
  }
}

resource "google_secret_manager_secret" "manager_secret" {
  for_each = { for secret in var.secrets : secret.name => secret }

  secret_id = each.value.name

  replication {
    user_managed {
      replicas {
        location = var.gcp_location
      }
      replicas {
        location = var.gcp_replication_location
      }
    }
  }
}

# Secret versions
resource "google_secret_manager_secret_version" "secret_versions" {
  for_each = { for secret in var.secrets : secret.name => secret }

  secret      = google_secret_manager_secret.manager_secret[each.key].id
  secret_data = each.value.value
  deletion_policy = var.deletion_policy

  lifecycle {
    create_before_destroy = true
  }
}

Our Terraform implementation follows several infrastructure-as-code best practices:

1. Variable Parameterization: Everything is parameterized for flexibility across environments

2. Resource Isolation: Clear separation between network, compute, and storage resources

3. Lifecycle Management: Strategic use of lifecycle blocks to prevent unnecessary resource updates

4. Secret Handling: Using Secret Manager properly instead of embedding secrets in Terraform files

5. Cross-Cloud Management: Single codebase managing both OCI and GCP resources

Observability and Monitoring Strategy

For monitoring and observability, we leverage Google Cloud's native capabilities:

1. Cloud Monitoring: Provides real-time metrics on our Cloud Run instances, including:

   • Request latency and throughput

   • Instance count and CPU utilization

   • Memory usage and garbage collection metrics

   • Error rates and response codes

2. Cloud Logging: Centralized logging solution that captures:

   • Authentication events and failures

   • Performance bottlenecks

   • Application errors and exceptions

   • Infrastructure changes

This approach takes advantage of the built-in integration between Cloud Run and Google's operations suite, eliminating the need for custom agents or complex configurations. For our Oracle ATP database, we use OCI's monitoring capabilities while forwarding critical alerts to our centralized monitoring solution.

Business Value Delivered

Empowering Development Teams

Our Keycloak implementation has transformed how our development teams approach authentication and authorization. Previously, each team implemented their own authentication logic, creating inconsistencies, security vulnerabilities, and maintenance overhead. Now:

• Frontend developers focus exclusively on creating compelling user experiences

• Backend developers concentrate on business logic and domain-specific functionality

• Security protocols are consistently implemented across all applications

• New applications can be integrated into our authentication ecosystem in days, not weeks

As our lead application developer noted: "Having a centralized identity provider managed by the platform team means we can deliver business features faster while being more secure."

Enhanced End-User Experience

For end users, our implementation provides:

• Single Sign-On: Users authenticate once to access all our services

• Self-Service Profile Management: Users control their own information

• Flexible Multi-Factor Authentication: Options including SMS, email, and authenticator apps

• Cross-Platform Consistency: The same authentication flow on web, mobile, and desktop

• Progressive Security: Step-up authentication for sensitive operations

These capabilities have measurably improved our user retention and engagement metrics, with a 23% reduction in abandoned authentication attempts.

Operational Efficiency

The dual-instance architecture delivers significant operational benefits:

• Reduced Attack Surface: Administrative functions are completely isolated from public access

• Independent Scaling: Resources are allocated based on actual usage patterns

• Controlled Change Management: Administrative changes can be made without affecting customer-facing systems

• Simplified Compliance: Clear separation simplifies audit requirements and reporting

Cost Optimization

Our approach delivers substantial cost advantages:

• Elimination of Per-User Licensing: Saving compared to equivalent commercial solutions

• Efficient Resource Utilization: Cloud Run's serverless model ensures we only pay for resources when actively processing authentication requests

• Development Efficiency: Centralizing authentication reduces development costs across projects

• Support Cost Reduction: Fewer identity-related support tickets since implementation

Implementation Challenges and Solutions

Our journey wasn't without obstacles:

Oracle ATP Connection Stability

Initially, we experienced intermittent connection issues between Keycloak and OCI ATP. We resolved this by:

1. Implementing connection pooling optimizations

2. Customizing Oracle JDBC driver settings

3. Configuring appropriate timeout and retry logic

Cold Start Performance

Cloud Run's serverless nature initially caused slow authentication during traffic spikes. We addressed this by:

1. Implementing min-instances=1 for the external instance during business hours

2. Enabling CPU boost for faster container startup

3. Optimizing JVM heap settings for faster initialization

Automated CI/CD Pipeline

A critical aspect of our implementation is the fully automated deployment pipeline. We've established a GitHub Actions workflow that handles the entire process from build to deployment:

name: Auth Client Deployment

on:
  push:
    branches: [ keycloak-client ]

env:
  GCP_WIF_PROJECT_ID: "project-wif-843"
  GCP_WIF_POOL: "auth-server-gh-pool"
  GCP_WIF_PROVIDER: "auth-server-gh-prov"
  PROJECT_LOCATION: europe-west1
  PROJECT_ID: project-prod843
  GCP_ARTIFACT_REGISTRY_NAME: project-repository
  DOCKER_IMAGE: keycloak-oracle-client

jobs:
  deploy:
    name: "Deploy Client Auth Server"
    runs-on: ubuntu-latest
    environment: prod
    permissions:
      contents: 'read'
      id-token: 'write'

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      # Authentication using Workload Identity Federation
      - id: 'auth'
        name: 'Authenticate to Google Cloud'
        uses: 'google-github-actions/auth@v2'
        with:
          create_credentials_file: true
          workload_identity_provider: 'projects/${{ env.GCP_WIF_PROJECT_NUMBER }}/locations/global/workloadIdentityPools/${{ env.GCP_WIF_POOL }}/providers/${{ env.GCP_WIF_PROVIDER }}'
          service_account: '${{ env.GCP_WIF_SA }}@${{ env.GCP_WIF_PROJECT_ID }}.iam.gserviceaccount.com'

      # Semantic versioning automation
      - name: Retrieve information on existing releases
        id: get_release_info
        run: |
          RELEASE_TAG=$(curl -L -H "Accept: application/vnd.github+json" -H "Authorization: Bearer ${{ secrets.GITHUB_TOKEN }}" -H "X-GitHub-Api-Version: 2022-11-28" https://api.github.com/repos/${{ github.repository }}/releases/latest |  jq -r '.tag_name')
          MAJOR=$(echo $RELEASE_TAG | awk -F. '{print $1}')
          MINOR=$(echo $RELEASE_TAG | awk -F. '{print $2}')
          PATCH=$(echo $RELEASE_TAG | awk -F. '{print $3}')
          PATCH=$((PATCH + 1))
          NEXT_VERSION="${MAJOR}.${MINOR}.${PATCH}"
          NEXT_VERSION=$(echo $NEXT_VERSION | sed 's/^v//')
          echo "NEXT_VERSION=${NEXT_VERSION}" >> $GITHUB_ENV

      # Container build and deployment
      - name: Build Container
        working-directory: ./keycloak-oci-atp/dev
        run: |-
          docker build -t "${PROJECT_LOCATION}-docker.pkg.dev/${PROJECT_ID}/${GCP_ARTIFACT_REGISTRY_NAME}/${DOCKER_IMAGE}:${{ env.NEXT_VERSION }}" .

      - name: Deploy to cloud run
        working-directory: ./keycloak-oci-atp/dev
        run: |-
          gcloud run deploy auth-ext \
            --image "${PROJECT_LOCATION}-docker.pkg.dev/${PROJECT_ID}/${GCP_ARTIFACT_REGISTRY_NAME}/${DOCKER_IMAGE}:${{ env.NEXT_VERSION }}" \
            --platform managed \
            --project ${PROJECT_ID} \
            --region ${PROJECT_LOCATION} \
            --allow-unauthenticated \
            --memory=2048Mi \
            --cpu 2 \
            --min-instances=0 \
            --max-instances=3 \
            --service-account=keycloak-client-sa@${PROJECT_ID}.iam.gserviceaccount.com \
            --update-secrets=KC_DB_PASSWORD=KC_DB_PASSWORD:latest \
            --timeout=3600s \
            --cpu-boost \
            --port=8080 \
            --ingress=all \
            --execution-environment=gen2

This pipeline provides several key advantages:

1. Automated Versioning: Semantic version increments with each deployment

2. Zero-Touch Deployment: Complete automation from commit to development environment after Pair Testing in Feature Branch and Merging

3. Secure Authentication: Using Google's Workload Identity Federation for keyless authentication

4. Secret Management: Sensitive configuration is managed through Cloud Secret Manager

5. Immutable Deployments: Each release creates a versioned container image

Integration with HashiCorp Vault

Our Keycloak implementation connects directly with our HashiCorp Vault infrastructure through OIDC, creating a comprehensive security ecosystem:

1. Identity Federation: Keycloak serves as the identity provider for Vault

2. Certificate Management: Vault manages SSL/TLS certificates for applications

3. Secret Rotation: Automated database credential rotation through Vault

4. Centralized Policy Management: Access policies coordinated between systems

This integration allows us to maintain a single source of truth for identity while leveraging Vault's advanced secret management capabilities.

Multi-Cloud Secret Management Approach

We've implemented a hybrid approach to secrets management that leverages the strengths of both cloud-native and open-source solutions:

1. Google Secret Manager: Used for storing Keycloak admin passwords and other GCP-specific credentials, benefiting from tight integration with GCP IAM and Cloud Run

2. HashiCorp Vault: Handles more complex secret management requirements, with Keycloak providing OIDC-based authentication for accessing Vault

This approach gives us the advantages of cloud-native integration where appropriate while maintaining flexibility through open standards. By using Keycloak as the identity provider for Vault, we maintain a single source of truth for authentication while leveraging each tool's strengths.

Looking Forward

With our foundation now established, we're exploring several enhancements:

1. Federation with External Identity Providers: Allowing customers to use existing corporate credentials like Google, Facebook ...

2. Advanced Threat Protection: Implementing risk-based authentication flows

3. Deeper Analytics: Gaining insights into authentication patterns to proactively address potential issues

4. Custom Authentication Flows: Building domain-specific authentication experiences

5. Disaster Recovery Planning: Developing cross-region failover capabilities to further enhance availability

Breaking Free from Vendor Lock-in

One of the most significant business advantages of our approach is the reduction of vendor lock-in. By combining open-source technologies (Keycloak) with cloud-agnostic containerization and serverless deployment patterns:

1. Flexible Infrastructure: Our solution can run on any cloud provider or on-premises environment that supports containers

2. Avoidance of Proprietary APIs: We rely on standard protocols and interfaces rather than provider-specific services

3. Cost Negotiation Leverage: The ability to migrate provides negotiating power with cloud providers

4. Risk Mitigation: Protection against service discontinuation or unfavorable terms changes

Cost Benefits of Open Source + Serverless

Our implementation delivers substantial cost optimization through the synergy of open source and serverless technologies:

1. Elimination of Licensing Costs: Open-source Keycloak removes per-user fees typical of commercial identity solutions

2. Pay-per-Use Infrastructure: Cloud Run's serverless model means we only pay for actual authentication traffic

3. Right-sized Resource Allocation: Independent scaling for admin and client instances optimizes resource utilization

4. Reduced Operational Overhead: Managed services minimize the need for dedicated infrastructure management

5. Development Efficiency: Standardized authentication reduces per-application development costs

This model transforms identity from a fixed cost to a variable cost that scales with actual usage.

Conclusion

The combination of Keycloak, containerization, and serverless deployment represents a modern approach to identity that delivers enterprise-grade functionality without vendor lock-in or prohibitive licensing costs. This architecture not only meets current requirements but also provides the flexibility to adapt to future needs without major reimplementation.

Most importantly, by handling the complexities of authentication and authorization through this centralized service, we've empowered our development teams to focus on what truly matters: creating business value through domain-specific applications and experiences.

*********************

Specialising in Cloud Architecture and Application Modernisation, Saha Merlin is a Cloud Solutions Architect and DevSecOps Specialist who helps organizations build scalable, secure, and sustainable infrastructure. With six years of specialized experience in highly regulated industries—split equally between insurance and finance—he brings deep understanding of compliance requirements and industry-specific challenges to his technical implementations.

His expertise spans various deployment models including Container-as-a-Service (CaaS), Infrastructure-as-a-Service (IaaS), and serverless platforms that drive business outcomes through technical excellence. He strategically implements open source technologies, particularly when SaaS solutions fall short or when greater control and autonomy are essential to meeting business requirements.

Saha integrates DevSecOps practices, Green IT principles to minimize environmental impact, and Generative AI to accelerate innovation. With a solid foundation in Software Engineering and nine years of diverse industry experience, he designs cloud-native solutions that align with both industry standards and emerging technological trends.

The Business Case for Automated SSL Encryption

Modern enterprises face significant challenges in maintaining secure digital infrastructure:

• Security Risks: Unencrypted connections expose sensitive data to potential breaches

• Compliance Demands: Many industries require continuous HTTPS protection

• Cost Pressures: Traditional SSL certificates can be expensive and complex to manage

Let's Encrypt offers a game-changing solution: free, automated SSL certificates that integrate seamlessly with Kubernetes environments.

Technical Dive: SSL Implementation

Prerequisites

Before diving into the implementation, ensure you have:

• A Kubernetes cluster (we'll use Google Kubernetes Engine as our reference architecture)

• Configured kubectl command-line tool

• A domain name mapped to your cluster's load balancer IP

Implementation

Step 1: Cluster Authentication and Preparation

Authenticate and connect to your GKE cluster using the following commands:

bashgcloud auth login
sudo apt-get install google-cloud-sdk-gke-gcloud-auth-plugin
gcloud container clusters get-credentials <cluster-name> --zone <cluster-location> --project <project-id>
kubectl get nodes

Step 2: Deploy Cert-Manager - The SSL Automation Engine

Cert-Manager is a crucial Kubernetes addon that automates TLS certificate management:

bashkubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.14.5/cert-manager.yaml
kubectl -n cert-manager get all

Staged Rollout Strategy

We'll implement a two-phase deployment to minimize risks:

1. Staging Environment

   • Uses Let's Encrypt's staging server

   • Allows testing without rate limits

   • Validates configuration before production deployment

2. Production Environment

   • Switches to Let's Encrypt's production certificate

   • Enables full, trusted SSL protection

Deploy in staging environement

# issuer-lets-encrypt-staging.yaml
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt-staging
  namespace: <your-app-namespace>
spec:
  acme:
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    email: <your-email>
    privateKeySecretRef:
      name: letsencrypt-staging
    solvers:
      - http01:
          ingress:
            name: web-ingress

Create an empty Secret for your SSL certificate before reconfiguring the Ingress and apply it.

# secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: web-ssl
  namespace: <your-app-namespace>
type: kubernetes.io/tls
stringData:
  tls.key: ""
  tls.crt: ""

Apply your empty secret

kubectl apply -f ssl/secret.yaml
kubectl apply -f issuer-lets-encrypt-staging.yaml
kubectl describe issuers.cert-manager.io letsencrypt-staging -n <your-app-namespace>

Step 3: Create Ingress controller

# ingress.yml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
  namespace: <your-app-namespace>
  annotations:
    kubernetes.io/ingress.allow-http: "true"
    kubernetes.io/ingress.global-static-ip-name: "lb-static-ip"
    cert-manager.io/issuer: letsencrypt-staging
spec:
  tls:
   - secretName: web-ssl
     hosts:
      - <your-domain.com>
  rules:
    - host: <your-domain.com>
      http:
        paths:
          - path: /*
            pathType: ImplementationSpecific
            backend:
              service:
                name: app
                port:
                  number: 80

Test it to check the content of your application (it can take arround 5 minutes to propagate)

curl -v --insecure https://yourdomain.com

Step 4: Deploy in production

Once staging validation succeeds, transition to the production Let's Encrypt server

# issuer-lets-encrypt-production.yaml
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt-production
  namespace: <your-app-namespace>
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: <your-email>
    privateKeySecretRef:
      name: letsencrypt-production
    solvers:
      - http01:
          ingress:
            name: web-ingress

Switch SSL to Production

kubectl apply -f issuer-lets-encrypt-production.yaml
kubectl annotate ingress web-ingress cert-manager.io/issuer=letsencrypt-production --overwrite -n <your-app-namespace>
curl -v https://yourdomain.com # wait 5 minutes min before test

Congratulations

Key Business Benefits

1. Cost Optimization: Zero-cost SSL certificates

2. Automated Management: Automatic certificate renewal

3. Reduced Operational Overhead: Simplified SSL infrastructure

4. Enhanced Security Posture: Continuous HTTPS protection

Operational Insights

• Cert-Manager automatically handles certificate renewal

• You'll receive email notifications 30 days before certificate expiration

• The entire process is repeatable across different Kubernetes environments

Conclusion

Implementing Let's Encrypt SSL in Kubernetes is no longer a complex technical challenge but a strategic business enabler. By following this guide, organizations can dramatically improve their digital security while maintaining operational efficiency.

Pro Tip: Always test in staging first and monitor your certificate's status to ensure uninterrupted service.

Introduction

HashiCorp Vault is a powerful secrets management tool that helps organizations secure, store, and control access to tokens, passwords, certificates, and encryption keys. One challenge with managing Vault is the need to unseal it after each restart, which can be cumbersome in automated environments. This article demonstrates how to automate the Vault unsealing process using Google Cloud KMS and deploy the solution to Google Cloud Run for a serverless, scalable, and cost-effective setup.

I'll walk through the entire process, including:

1. Setting up GCP resources with Terraform

2. Configuring Vault for auto-unsealing with GCP KMS

3. Creating a Docker container for Vault

4. Deploying to Cloud Run

5. Automating deployment with GitHub Actions

6. Migrating from Shamir key shares to GCP KMS auto-unsealing

Prerequisites

• Google Cloud Platform account with a project

• GCP service account with appropriate permissions

• Basic knowledge of Terraform, Docker, and Vault

• HashiCorp Vault CLI installed locally

• GitHub repository for CI/CD (optional)

Setting Up Environment Variables

Start by setting up environment variables for your deployment:

export PROJECT_ID=gcp_project_id
export GCP_LOCATION=europe-west1
export GCP_ARTIFACT_REGISTRY_NAME=docker-repository
export DOCKER_IMAGE=vault-server
export CLOUD_RUN_SERVICE_NAME=vault-server

GCP Resources with Terraform

Required IAM Roles for Vault Service Account

The Vault service account needs the following roles to interact with GCP services:

roles/cloudkms.viewer
roles/cloudkms.cryptoKeyEncrypterDecrypter or roles/cloudkms.signerVerifier
roles/secretmanager.secretAccessor
roles/storage.objectAdmin

Terraform Configuration

Create a Terraform configuration file to set up the necessary GCP KMS resources:

resource "google_kms_key_ring" "keyring" {
  name     = "${var.name}-keyring"
  location = var.location
  project  = var.project
}
​
resource "google_kms_crypto_key" "key" {
  name            = "${var.name}-key"
  key_ring        = google_kms_key_ring.keyring.id
  rotation_period = var.rotation_period
  purpose         = var.purpose
}
​
resource "google_kms_crypto_key_iam_binding" "iam" {
  crypto_key_id = google_kms_crypto_key.key.id
  role          = "roles/cloudkms.cryptoKeyEncrypterDecrypter"
​
  members = [
    "serviceAccount:${var.vault_service_account}@${var.project}.iam.gserviceaccount.com"
  ]
}
​
variable "name" {
  default = "vault-unseal"
}
variable "location" {
  default = "global"
}
variable "project" {}
variable "rotation_period" {
  default = "7776000s"  # 90 days
}
variable "purpose" {
  default = "ENCRYPT_DECRYPT"
}
variable "vault_service_account" {}

You'll also need to create a Google Cloud Storage bucket for Vault's storage backend:

resource "google_storage_bucket" "storage-bucket" {
  name          = var.bucket_name
  location      = var.location
  force_destroy = var.force_destroy
  uniform_bucket_level_access = var.uniform_bucket_level_access
  public_access_prevention = var.public_access_prevention
​
  storage_class = var.storage_class
  versioning {
    enabled = true
  }
}
​
​
variable "bucket_name" {
  default = "vault-server-bucket"
}
variable "location" {
  default = "EU"
}
variable "uniform_bucket_level_access" {
  type    = bool
  default = true
}
variable "storage_class" {
  default = "STANDARD"
}
​
variable "force_destroy" {
  type    = bool
  default = false
}
​
variable "public_access_prevention" {
  default = "enforced"
}

Configuring Vault for Auto-Unsealing

Create a vault-config.hcl file for your Vault configuration:

seal "gcpckms" {
  project     = "gcp_project_id"
  region      = "global"
  key_ring    = "vault-unseal-keyring"
  crypto_key  = "vault-unseal-key"
}
​
storage "gcs" {
  bucket = "vault-server-bucket"
}
​
listener "tcp" {
  address     = "0.0.0.0:8080"
  tls_disable = 0  # Enabling TLS
}

Note: Make sure to replace gcp_project_id with your actual GCP project ID. For production deployments, you should properly configure TLS with certificates rather than using tls_disable = 0.

Creating the Vault Docker Container

Dockerfile

Create a Dockerfile for the Vault container:

FROM hashicorp/vault:1.19.0
​
# Create a non-root user and group
RUN addgroup -S vaultgroup && adduser -S vaultuser -G vaultgroup
​
RUN mkdir -p /vault/config
​
COPY config/vault-config.hcl /vault/config/vault-config.hcl
​
# Set proper ownership for Vault directories and files
RUN chown -R vaultuser:vaultgroup /vault
​
# Use the non-root user
USER vaultuser
​
ENTRYPOINT ["vault", "server", "-config=/vault/config/vault-config.hcl"]

Make sure your project structure looks like this:

project/
├── config/
│   └── vault-config.hcl
├── Dockerfile
└── terraform/
    └── main.tf

Building and Pushing the Docker Image Manually

If you're not using CI/CD, you can build and push the Docker image manually:

# Build Container
docker build -t "${GCP_LOCATION}-docker.pkg.dev/${PROJECT_ID}/${GCP_ARTIFACT_REGISTRY_NAME}/${DOCKER_IMAGE}:latest" .
​
# Authenticate with Artifact Registry
gcloud auth configure-docker ${GCP_LOCATION}-docker.pkg.dev
​
# Push Container
docker push "${GCP_LOCATION}-docker.pkg.dev/${PROJECT_ID}/${GCP_ARTIFACT_REGISTRY_NAME}/${DOCKER_IMAGE}:latest"

Automating Deployment with GitHub Actions

For a more robust deployment process, you can use GitHub Actions to automate the build and deployment of your Vault server. Create a file named .github/workflows/deploy-vault.yml with the following content:

name: Vault Server Deployment
​
on:
  push:
    branches: [ vault-server ]
​
env:
  GCP_WIF_PROJECT_ID: "org-wif-project"
  GCP_WIF_PROJECT_NUMBER: ${{ secrets.GCP_WIF_PROJECT_NUMBER }}
  GCP_WIF_POOL: "auth-server-gh-pool"
  GCP_WIF_PROVIDER: "auth-server-gh-prov"
  GCP_WIF_SA: "github-org-auth-sa"
  RELEASE_TOKEN: ${{ secrets.RELEASE_TOKEN }}
​
  PROJECT_LOCATION: europe-west1
  PROJECT_ID: org-env-project
  GCP_ARTIFACT_REGISTRY_NAME: docker-repository
  DOCKER_IMAGE: vault-server
  GCP_IMPERSONATED_SA_LIFETIME_TOKEN: 300 # 5 minutes
​
jobs:
  deploy:
    name: "Deploy Vault"
    runs-on: ubuntu-latest
    environment: test
    permissions:
      contents: 'read'
      id-token: 'write'
​
    steps:
      - name: Checkout
        uses: actions/checkout@v4
​
      - name: Set up Cloud SDK
        uses: google-github-actions/setup-gcloud@v1
​
      - id: 'auth'
        name: 'Authenticate to Google Cloud'
        uses: 'google-github-actions/auth@v2'
        with:
          create_credentials_file: true
          workload_identity_provider: 'projects/${{ env.GCP_WIF_PROJECT_NUMBER }}/locations/global/workloadIdentityPools/${{ env.GCP_WIF_POOL }}/providers/${{ env.GCP_WIF_PROVIDER }}'
          service_account: '${{ env.GCP_WIF_SA }}@${{ env.GCP_WIF_PROJECT_ID }}.iam.gserviceaccount.com'
​
      - name: Retrieve information on existing releases
        id: get_release_info
        run: |
          RELEASE_TAG=$(curl -L -H "Accept: application/vnd.github+json" -H "Authorization: Bearer ${{ secrets.GITHUB_TOKEN }}" -H "X-GitHub-Api-Version: 2022-11-28" https://api.github.com/repos/${{ github.repository }}/releases/latest |  jq -r '.tag_name')
          echo "Latest release tag: $RELEASE_TAG"
          MAJOR=$(echo $RELEASE_TAG | awk -F. '{print $1}')
          MINOR=$(echo $RELEASE_TAG | awk -F. '{print $2}')
          PATCH=$(echo $RELEASE_TAG | awk -F. '{print $3}')
          PATCH=$((PATCH + 1))
          NEXT_VERSION="${MAJOR}.${MINOR}.${PATCH}"
          NEXT_VERSION=$(echo $NEXT_VERSION | sed 's/^v//')  # Remove the "v" from the beginning of the version
          echo "NEXT_VERSION=${NEXT_VERSION}" >> $GITHUB_ENV
          echo "Next version: $NEXT_VERSION"
​
      - name: Build Container
        working-directory: ./vault-server
        run: |-
          docker build -t "${PROJECT_LOCATION}-docker.pkg.dev/${PROJECT_ID}/${GCP_ARTIFACT_REGISTRY_NAME}/${DOCKER_IMAGE}:${{ env.NEXT_VERSION }}" .
​
      - name: Authenticate Artifact Registry
        run: |-
          gcloud -q auth configure-docker ${{ env.PROJECT_LOCATION }}-docker.pkg.dev
​
      - name: Push Container
        run: |-
          docker push "${PROJECT_LOCATION}-docker.pkg.dev/${PROJECT_ID}/${GCP_ARTIFACT_REGISTRY_NAME}/${DOCKER_IMAGE}:${{ env.NEXT_VERSION }}"
​
      - name: Deploy to cloud run
        working-directory: ./vault-server
        run: |-
          gcloud run deploy vault-server \
            --image "${PROJECT_LOCATION}-docker.pkg.dev/${PROJECT_ID}/${GCP_ARTIFACT_REGISTRY_NAME}/${DOCKER_IMAGE}:${{ env.NEXT_VERSION }}" \
            --platform managed \
            --project ${PROJECT_ID} \
            --region ${PROJECT_LOCATION} \
            --no-allow-unauthenticated \
            --service-account=vault-server-sa@${PROJECT_ID}.iam.gserviceaccount.com \
            --update-secrets=/vault/credentials/gcp-vault-agent-sa.json=VAULT_AGENT_SA:latest \
            --memory=1024Mi \
            --cpu 1 \
            --min-instances=0 \
            --max-instances=3 \
            --timeout=3600s \
            --cpu-boost \
            --port=8080 \
            --ingress=all \
            --execution-environment=gen2
​
      - name: Create a release
        uses: actions/create-release@v1
        env:
          GITHUB_TOKEN: ${{ secrets.RELEASE_TOKEN }}
        with:
          tag_name: ${{ env.NEXT_VERSION }}
          release_name: Version ${{ env.NEXT_VERSION }}
          body: Release notes for vault version ${{ env.NEXT_VERSION }}

This workflow does the following:

1. Authenticates to Google Cloud using Workload Identity Federation

2. Retrieves the latest release version and increments it

3. Builds the Vault Docker image

4. Pushes the image to Google Artifact Registry

5. Deploys the image to Cloud Run

6. Creates a new GitHub release

Note: To use this workflow, you'll need to set up Workload Identity Federation and add the required secrets to your GitHub repository.

Deploying to Cloud Run Manually

If you're not using CI/CD, you can deploy to Cloud Run manually:

gcloud run deploy ${CLOUD_RUN_SERVICE_NAME} \
  --image "${GCP_LOCATION}-docker.pkg.dev/${PROJECT_ID}/${GCP_ARTIFACT_REGISTRY_NAME}/${DOCKER_IMAGE}:latest" \
  --platform managed \
  --project ${PROJECT_ID} \
  --region ${GCP_LOCATION} \
  --no-allow-unauthenticated \
  --service-account=vault-server-sa@${PROJECT_ID}.iam.gserviceaccount.com \
  --update-secrets=/vault/credentials/gcp-vault-agent-sa.json=VAULT_AGENT_SA:latest \
  --memory=1024Mi \
  --cpu 1 \
  --min-instances=0 \
  --max-instances=3 \
  --timeout=3600s \
  --cpu-boost \
  --port=8080 \
  --ingress=all \
  --execution-environment=gen2

Security Note: In a production environment, you should keep --no-allow-unauthenticated for proper authentication for your Vault server rather than using --allow-unauthenticated. Consider setting up Identity-Aware Proxy (IAP) or another authentication mechanism.

Setting Up and Using the Vault CLI

Install the Vault CLI locally to interact with your deployed Vault server:

# For macOS
brew tap hashicorp/tap
brew install hashicorp/tap/vault
​
# Verify installation
vault version
​
# Configure CLI to talk to your Vault server
export VAULT_ADDR="https://vault.yourdomain.com"
​
# Check Vault status
vault status

Migrating from Shamir Keys to GCP KMS Auto-Unsealing

If you're migrating an existing Vault installation from Shamir key shares to GCP KMS auto-unsealing, follow these steps:

1. Update your Vault configuration to include the gcpckms seal stanza

2. Restart Vault

3. Unseal Vault with the -migrate flag:

# Provide three of your five Shamir unseal keys with the -migrate flag
vault operator unseal -migrate <UNSEAL_KEY_1>
vault operator unseal -migrate <UNSEAL_KEY_2>
vault operator unseal -migrate <UNSEAL_KEY_3>
​
# Verify the migration was successful
vault status

After successful migration, you should see output similar to:

Key                      Value
---                      -----
Seal Type                gcpckms
Recovery Seal Type       shamir
Initialized              true
Sealed                   false
Total Recovery Shares    5
Threshold                3
Version                  1.19.0
Build Date               2025-03-04T12:36:40Z
Storage Type             gcs
Cluster Name             vault-cluster-xxxxxx
Cluster ID               sssss-5a16sc405-89c1-s333333ffffff
HA Enabled               true

Note that the Shamir keys are now recovery keys for use in emergency situations.

Setting Up Authentication Methods (Optional)

After your Vault is up and running with auto-unsealing, you might want to configure authentication methods:

OIDC Authentication

# Enable OIDC auth method
vault auth enable oidc
​
# Configure OIDC
vault write auth/oidc/config \
  oidc_discovery_url="https://oidc.yourdomain.com/realms/vault" \
  oidc_client_id="vault-client" \
  oidc_client_secret="your-client-secret" \
  default_role="reader"

AppRole Authentication for Applications

# Enable AppRole auth method
vault auth enable approle
​
# Create a policy for the Vault agent
vault policy write vault-agent-policy - <<EOF
path "secret/data/*" {
  capabilities = ["read"]
}
EOF
​
# Create an AppRole with the policy attached
vault write auth/approle/role/vault-agent \
  token_policies="vault-agent-policy" \
  token_ttl=1h \
  token_max_ttl=2h \
  secret_id_ttl=1h \
  bind_secret_id=true
​
# Get Role ID
vault read auth/approle/role/vault-agent/role-id
​
# Generate a Secret ID
vault write -f auth/approle/role/vault-agent/secret-id

Conclusion

By configuring HashiCorp Vault with Google Cloud KMS for auto-unsealing and deploying it to Cloud Run, we've created a serverless, fully managed secrets management solution that automatically unseals itself after restarts. The CI/CD pipeline with GitHub Actions further enhances this setup by automating the deployment process, making version management easy and repeatable, and our use of GCP Secret Manager ensures that sensitive initialization data is securely stored.

This approach eliminates the operational burden of manual unsealing while maintaining the security benefits of Vault's seal mechanism. The combination of GCP KMS for auto-unsealing, Secret Manager for secure storage, Cloud Run for deployment, and GitHub Actions for CI/CD provides a scalable, resilient, and cost-effective secrets management solution that can grow with your organization's needs.

Next Steps

• Set up proper TLS certificates for your Vault instance

• Configure additional authentication methods as needed

• Implement audit logging

• Enhance your CI/CD pipeline with testing

• Implement backup and disaster recovery procedures

• Consider setting up Vault HA for higher availability

Resources

• HashiCorp Vault Documentation

• GCP KMS Auto-Unseal

• Vault on Google Cloud

• Cloud Run Documentation

• GitHub Actions Documentation

• GCP Secret Manager

This article represents a practical implementation based on real-world experience deploying HashiCorp Vault on Google Cloud Platform. While this setup works well for many use cases, always assess your specific security requirements before implementing any secrets management solution in production.

In early 2025, I undertook a cost optimization project for a startup running a legacy Java/Servlet/JSP application. The goal was to reduce hosting costs while maintaining or improving infrastructure quality. This post details our journey from an OVH VPS to Oracle Cloud Infrastructure (OCI) Free Tier, resulting in a €0/month hosting cost while gaining enterprise-grade features.

Initial Situation Analysis

Legacy Environment

• Application Stack: Java/Servlet/JSP

• Build System: No Maven/Gradle

• Deployment: Direct WAR deployment

• Infrastructure: OVH VPS

• Monthly Costs:

  • VPS: €15.98

  • Backup Service: €6.00

  • Total: €21.98/month

Technical Debt Overview

• No containerization

• Manual deployment process

• Basic backup system

• Limited security features

• No Infrastructure as Code

Cloud Provider Selection Process

We conducted a thorough analysis of major cloud providers based on the following criteria:

Google Cloud Platform

• Costs for equivalent setup: €115.89 - €136.86/month

• Breakdown:

  • Compute (n1-standard-1): €34.67

  • Database: ~€101.40

  • Storage: €0.10

  • External IP: €7.29

  • DNS: €0.65

• Free tier: Limited duration and resources

Oracle Cloud Infrastructure

• Free Tier Resources:

  • 2 AMD or 4 ARM OCPUs

  • 24GB RAM

  • 200GB Block Storage

  • Autonomous Database

  • Load Balancer

  • 10TB/month outbound bandwidth

• Enterprise Features Included:

  • Web Application Firewall

  • Bastion Service

  • Cloud Guard

  • Vulnerability Scanning

  • Automated Backups

Decision Factors

1. Cost Efficiency: OCI's permanent free tier

2. Resource Allocation: Generous compute and memory

3. Enterprise Features: Included security and monitoring

4. Long-term Viability: No time limitation on free tier

Migration Strategy

Why Lift-and-Shift?

1. Resource Constraints

   • Limited budget for immediate modernization

   • Team focused on product development

   • No immediate technical debt impact

2. Future-Proofing

   • Zero hosting costs enable gradual modernization

   • Infrastructure ready for containerization

   • Automated deployment pipeline in place

Infrastructure as Code Implementation

Terraform Backend Configuration

We used Terraform Cloud for state management and team collaboration. Here's our backend configuration:

# backend.tf
terraform {
  required_version = ">= 1.1.0"
  backend "remote" {
    hostname     = "app.terraform.io"
    organization = "[Organization Name]"

    workspaces {
      name = "prod"
    }
  }
}

This setup provides several benefits:

• Secure state file storage

• State locking to prevent concurrent modifications

• Team collaboration capabilities

• Version control integration

• Automated state backups

• Run history and audit trail

Our Terraform project structure:

terraform/
├── modules/
├── script/
├── backend.tf
├── data.tf
├── local.tf
├── main.tf
├── output.tf
├── primary.tf
├── providers.tf
├── secondary.tf
├── variables.tf
└── versions.tf

Implementation Timeline

1. Planning Phase (2 Days)

   • Infrastructure design

   • Migration strategy documentation

   • Resource allocation planning

2. Infrastructure Setup (2 Days)

   • Terraform configuration

   • Network setup

   • Security configuration

3. Application Migration (1 Day)

   • Database migration

   • File system replication

   • DNS configuration

4. Testing & Validation (2 Days)

   • Functionality testing

   • Performance validation

   • Security verification

5. Cutover (1 Day)

   • DNS switch

   • Final data sync

   • Go-live verification

Results and Benefits

1. Cost Reduction

   • Previous cost: €21.98/month

   • Current cost: €0/month

   • Annual savings: €263.76

2. Infrastructure Improvements

   • High availability architecture

   • Automated backups

   • Web Application Firewall

   • Bastion service

   • Enhanced monitoring

3. Operational Benefits

   • Infrastructure as Code

   • Automated deployments

   • Enhanced security

   • Improved disaster recovery

Future Roadmap

1. Application Modernization

   • Maven integration

   • Containerization

   • CI/CD pipeline enhancement

2. Infrastructure Evolution

   • Multi-region deployment

   • Container orchestration

   • Serverless adoption

Exemple Resources and Further Reading to start

• 1 year ago, i add on my Youtube Channel Complete implementation tutorial: Pipeline DevSecOps Oracle Cloud Gratuite, Jenkins, Trivy, OWASP, Docker Hub, Sonarqube, Terraform

• Infrastructure as Code templates: https://github.com/devsahamerlin/iac-spring-boot-atp-jenkins-oci-devsecops

Conclusion

This migration demonstrates that pragmatic cloud adoption doesn't always require immediate application modernization. By leveraging OCI's free tier, we eliminated hosting costs while creating a foundation for future improvements. The startup can now modernize at their own pace without infrastructure cost pressure.

The complete automation scripts, Infrastructure as Code templates, and configuration files are available in our GitHub repository. For a detailed walkthrough of setting up a complete DevSecOps pipeline on OCI Free Tier, check out our YouTube tutorial.

Tags: #CloudMigration #OCI #DevOps #IaC #CostOptimization #CloudArchitecture

Introduction

Modern enterprises require infrastructure that can support rapid innovation while ensuring robust security and reliability. Our architecture combines the power of Google Kubernetes Engine (GKE) with MongoDB Atlas to create a solution that addresses these needs through a comprehensive, security-first approach.

Core Architecture Components

Private Kubernetes Cluster

At the heart of our architecture lies a private GKE cluster, designed with security and isolation in mind. The cluster operates with internal IP addresses only, following RFC1918 standards for private networks. This approach ensures that nodes and pods are inherently isolated from the internet, creating a secure foundation for our applications.

The cluster features:

• Multi-zone deployment for high availability

• Node auto-provisioning for dynamic scaling

• Horizontal Pod Autoscaling (HPA) for workload optimization

• Private nodes with no public IP addresses

Security Implementation

Security is implemented in multiple layers throughout the architecture:

Identity and Access Management:

• Identity-Aware Proxy (IAP) controls access to applications

• Cloud IAM provides fine-grained access control

• Kubernetes Secrets manage sensitive configuration data

Network Security:

• Virtual Private Cloud (VPC) isolates resources

• Cloud Firewall rules control traffic flow

• SSL certificates secure HTTPS communications

• Cloud NAT enables secure outbound internet access

Security Monitoring and Prevention:

• Cloud Security Scanner identifies web vulnerabilities

• Security Command Center provides threat detection

• Checkov performs automated security analysis of infrastructure configurations

Database Layer

The MongoDB Atlas integration brings several crucial capabilities:

• Regional cluster deployment with multi-zone redundancy

• Automated backups and point-in-time recovery

• Network isolation through VPC peering

• IP Access Lists for controlled database access

CI/CD Pipeline

Our continuous integration and deployment pipeline leverages:

• GitHub for version control and collaboration

• Artifact Registry for container image management

• ArgoCD for GitOps-driven deployments

• Automated deployment system (Dispatch) for seamless updates

Monitoring and Maintenance

The architecture includes comprehensive monitoring through:

• Cloud Logging for centralized log management

• Cloud Monitoring for performance tracking

• Regular automated backups

• Jump Host for secure maintenance access

Business Benefits

Enhanced Security Posture

The multi-layered security approach significantly reduces the risk of breaches while maintaining compliance with industry standards. The private cluster design, combined with IAP and Cloud Security Command Center, provides comprehensive protection for sensitive workloads.

Operational Excellence

Automation plays a crucial role in reducing manual intervention and human error. The GitOps approach with ArgoCD ensures consistent deployments, while auto-scaling capabilities optimize resource utilization automatically.

Cost Optimization

Several features contribute to cost efficiency:

• Dynamic scaling adjusts resources based on demand

• Multi-zone deployment optimizes for availability without excessive redundancy

• Cloud CDN reduces bandwidth costs and improves performance

• Automated resource management prevents waste

Business Continuity

The architecture ensures business continuity through:

• Multi-zone deployment for high availability

• Automated backup solutions for both GKE and AKS

• Disaster recovery planning and implementation

• Real-time monitoring and alerting

Implementation Considerations

Network Design

The network architecture carefully balances security with accessibility:

• Cloud DNS manages domain name resolution

• VPC peering enables secure communication between networks

• Cloud Router facilitates dynamic route exchange

• Load balancers distribute traffic efficiently

Development Workflow

The development process is streamlined through:

• GitHub for collaborative development

• Terraform Cloud for infrastructure as code

• Integrated CI/CD pipeline

• Automated testing and security scanning

Future Considerations

The architecture is designed with future growth in mind:

• Potential integration with on-premises systems

• Multi-regional expansion capabilities

• Multi-cloud deployment options

• Continuous cost and performance optimization

Conclusion

This architecture represents a comprehensive approach to modern cloud infrastructure, combining security, scalability, and operational efficiency. By leveraging GCP's advanced services and MongoDB Atlas's robust database capabilities, it provides a solid foundation for enterprise applications while maintaining flexibility for future growth.

The implementation demonstrates how careful consideration of security, automation, and scalability can result in an architecture that not only meets current business needs but also positions organizations for future success. Through features like private clustering, automated security scanning, and GitOps-driven deployment, it establishes a framework that supports both rapid innovation and stable operations.

Organizations adopting this architecture can expect improved security posture, reduced operational overhead, and enhanced ability to scale their applications while maintaining control over costs and complexity. The architecture's emphasis on automation and security-first design makes it particularly suitable for enterprises handling sensitive workloads while requiring operational agility.

For organizations considering similar architectures, the key is to maintain focus on security, automation, and scalability while ensuring that the implementation aligns with specific business requirements and compliance needs.

📚 Want to implement this architecture? Check out these resources:

🎥 Video Tutorials (French):

• Secure GitHub Actions & GCP with Workload Identity Federation: https://www.youtube.com/watch?v=VzP6NhN-rW0

• Configure MongoDB Atlas with Terraform Cloud: https://www.youtube.com/watch?v=GbGBIU97sCY

• Connect Terraform Cloud to GCP via Workload Identity Federation: https://www.youtube.com/watch?v=ebV8VeNdscU

• Connect to GCP private resources with IAP: https://www.youtube.com/watch?v=FUqWOMvyWxo

📝 Technical Guides (English):

• Secure GitHub Actions-GCP Connection with Workload Identity Federation: https://merlin.microworka.com/establish-a-secure-connection-between-github-actions-and-google-cloud-platform-gcp-using-workload-identity-federation

• Link Terraform Cloud & GCP via Workload Identity Federation: https://merlin.microworka.com/how-to-safely-link-terraform-cloud-and-google-cloud-platform-via-workload-identity-federation

• Configure MongoDB Atlas with Terraform Cloud: https://merlin.microworka.com/easy-steps-to-configure-mongodb-atlas-with-terraform-and-terraform-cloud

• Set up ArgoCD on Private GKE for GitOp: https://merlin.microworka.com/setting-up-argocd-on-private-google-kubernetes-engine-cluster-for-gitops-deployment

#CloudArchitecture #GCP #MongoDB #DevOps #CloudSecurity #Infrastructure #TechInnovation #CloudComputing #Engineering

This blog post is part of our technical architecture series. For more detailed information about specific components or implementation guidance, please reach out to our team.

Prerequisites:

• A Google Cloud Platform (GCP) account

• gcloud command-line tool installed and authenticated

• A GitHub account

• A private Git repository for storing your Kubernetes manifests

Step 1: Create a GKE cluster Create a new private GKE cluster or use an existing one. Make sure to enable the necessary APIs and grant the required permissions for your GCP account.

# From jump host/autorised host
gcloud auth login
sudo apt-get install google-cloud-sdk-gke-gcloud-auth-plugin
gcloud compute start-iap-tunnel private-gke-jump-host 22 --local-host-port=localhost:<LOCAL_PORT> #you can use any open port or remove --local-host-port=localhost:49222 and let's use random port

ssh -J localhost:<LOCAL_PORT> 192.168.1.7

gcloud auth login
sudo apt-get install google-cloud-sdk-gke-gcloud-auth-plugin
gcloud container clusters get-credentials private-empmng-cluster --zone us-east4-c --project hand-on-lab-404211
gcloud config set run/region us-east4
gcloud auth configure-docker
kubectl get nodes

Step 2: Install ArgoCD Install ArgoCD on your GKE cluster using the official manifests

kubectl create namespace argocd

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
kubectl -n argocd get pods -w
kubectl -n argocd get svc

Step 3: Expose ArgoCD API Server

The ArgoCD API server allow you to access the web UI.

kubectl patch svc argocd-server -n argocd --type='json' -p '[{"op":"replace","path":"/spec/type","value":"NodePort"}]'
kubectl -n argocd get svc

Step 4: Access the ArgoCD Web UI

The ArgoCD web UI using the NodePort IP on localhost:8088 using port forwarding.

• Retreive the cluster node to use securely:

    kubectl get nodes
  

• Retrieve the initial admin password using the following command:

•       kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath='{.data.password}' | base64 -d
  

• Connect to the cluster node using IAP-tunnel, change <gke-private-cluster-node>, <argocd-node-port> (eg: 32347) and <cluster-location>

•       gcloud compute start-iap-tunnel <gke-private-cluster-node> <argocd-node-port> --local-host-port=localhost:8088 --zone=<cluster-location>
  

• Connect to ArgoCD Web UI using localhost:8088

Step 5: Configure ArgoCD with GitHub In the ArgoCD web UI, navigate to the "Settings" section, "Repositories" and connect ArgoCD to your GitHub account. You'll need to create a GitHub personal access token with the necessary permissions (repo, admin:repo_hook, read:user, user:email) and provide it to ArgoCD.

CONNECTION STATUS:

Step 6: Create an Application in ArgoCD

Create a new ArgoCD application and point it to your GitHub repository containing the Kubernetes manifests. Specify the repository URL, target revision (branch or tag), and the path to your manifests.

Navigate to the "Applications" section and click on "+ NEW APP".

• GENERAL section

• 

• SOURCE section

• 

• DESTINATION section

• 

Step 7: Sync and Deploy Once the application is created,

You can sync and deploy your Kubernetes resources to the GKE cluster. ArgoCD will continuously monitor the Git repository for changes and automatically sync the cluster with the desired state defined in the manifests.

Step 8: Verify the Deployment Verify that your Kubernetes resources are deployed correctly on the GKE cluster.

You can use the kubectl command or the GKE console to inspect the resources,

change <your-app-namespace>

kubectl get deployment -n <your-app-namespace>

Congratulations! You've successfully deployed ArgoCD on a private GKE cluster and set up GitOps deployment with GitHub. You can now leverage the power of GitOps to manage your Kubernetes resources in a declarative and version-controlled manner.

Note: This blog post provides a high-level overview of the steps involved. For more detailed instructions and troubleshooting, refer to the official ArgoCD documentation and GKE guides.

Youtube Demo Video: https://youtu.be/u7O1wqbChK0?t=729

My name is Merlin Saha, and I'm an experienced software developer into the exciting world of Cloud Architecture and DevOps Engineering. This blog post chronicles my journey, from my initial interest in Google Cloud to building a robust cloud resume showcasing my newfound skills and Multicloud Architect Certifed.

My journey has been anything but conventional

- I worked as a motorcycle taxi driver to found my IT course and Bachelor in Software Engineering.

These challenges instilled in me the perseverance and resourcefulness that now fuel my cloud journey.

The Spark: Discovering Cloud Architecture

Despide my first use of Google cloud in 2015 ant get my first MOOC Collections certificates on OnpenClassroom named Deploy your Java applications on the Google Cloud (Use Saha as name). While working as a Full-stack Software Engineer in 2021, I started develop great solutions with Google Cloud Platform(GCP). This experience ignited a desire to explore cloud architecture further. With limited knowledge, I embarked on a learning quest, starting with Coursera specializations "Architecting with Google Compute Engine" and "Developing Applications with Google Cloud."

Building a Strong Foundation

My learning extended to Google Cloud certifications, including the Cloud Engineer Professional Certificate, Cloud Architect Professional Certificate and Cloud DevOps Engineer Professional Certificate. I actively participated in Google Cloud Skills Boost to solidify my understanding of theoretical concepts and Practices. However, I yearned for practical experience with the real world project that i can share with the Cloud World.

Taking Initiative: Personal Projects and Real-World Challenges

To bridge the gap, I embarked on personal projects leveraging Google Cloud services. I built a 3-tier highly available application, further fueling my desire to showcase my skills to the world. This led me to Enter The Cloud Resume Challenge by Forrest Brazeal, an opportunity to demonstrate my capabilities as a certified GCP professional.

The Road is not Easy, with plenty of obstacles, but we must continue!

The Cloud Resume Challenge: A Proving Ground

The challenge resonated deeply. Here was a chance to showcase my expertise in cloud solutions and configurations, not just certifications. The challenge involved building a cloud-hosted resume utilizing serverless computing and DevOps practices.

The Challenge Breakdown:

• Building a Serverless Web App: The core challenge involves constructing a complete web application for your resume. Here, you'll leverage the power of serverless computing, eliminating the need to manage physical servers.

• Visitor Counter Integration: Spice things up by incorporating a visitor counter! This not only adds functionality but demonstrates your ability to integrate different components within the cloud environment.

• Cloud Certification Power Up: The challenge strongly recommends obtaining a cloud certification to solidify your foundational knowledge. This certification serves as a valuable credential for potential employers.

But Wait, There's More!

The Cloud Resume Challenge doesn't stop there. It offers a variety of "mod tracks" to expand your project and further hone your skills:

• Security Savvy: Delve into the world of cloud security practices, learning how to safeguard your application and data.

• DevOps Disciple: Embrace the DevOps philosophy by integrating continuous integration and continuous delivery (CI/CD) into your workflow, streamlining the development and deployment process.

Now that you're armed with this knowledge, it's time to move In the next part.

Cloud Resume Challenge: A Head Start with Certifications

But what if you already have a solid foundation in cloud technologies? Here's where your existing certifications can be a game-changer!

Fortunately, as we saw, before embarking on the challenge, I had already secured some key certifications:

• Google Cloud Certified Professional Cloud DevOps Engineer.

• Google Cloud Certified Professional Cloud Architect.

• Google Cloud Certified Associate Cloud Engineer

• Terraform Certified Associate 003.

These certifications not only bolstered my confidence for the challenge but to verify the necessary skills to excel in a Cloud Architecture and DevOps Engineering roles.

Let's Dive Deep: The Technical Backbone of Cloud Resume Challenge

We've talked about the challenge and my prep, but now it's time to unveil the real star of the show: the technical architecture behind my cloud resume! Buckle up, because we're about to get geeky.

Foundation: Multiple Projects for Multi-Stage Deployments with DevOps Practices

The Cloud Resume Challenge emphasizes best practices like utilizing separate environments for development, testing, and production. This perfectly aligns with the "DevOps Mod: All The World's A Stage" concept. However, I took the approach a step further by incorporating Workload Identity Federation for enhanced security.

Multi-Project Setup:

• Dedicated Project per Environment: Adhering to the Mod's recommendation, I created separate Google Cloud projects for each environment (Dev, QA, UAT, Prod) within our four-environment organization. This ensures isolated testing and resource management for each stage.

Workload Identity Federation Integration:

• Shared Workload Identity Project: Instead of a shared test project, I utilized a single Workload Identity Federation project. This project acts as a central hub, authenticating service accounts across all environment-specific projects.

• Secure Access for Workloads: Workload Identity Federation grants service accounts within each environment project the necessary permissions to access resources in that specific projects.

By embracing multi-environment deployments, I not only enhanced the robustness of my Cloud Resume but also improved my understanding of DevOps best practices as highlighted in the "DevOps Mod."

Embracing Automation: Cloud Resume Goes All In with DevOps Practices

The Cloud Resume Challenge doesn't stop at building a cool web application; it's also about showcasing your expertise in DevOps practices. Here's how I incorporated automation into my Cloud Resume project, exceeding the basic challenge requirements and aligning with the "DevOps Mod: Automation Nation."

Infrastructure as Code (IaC) CI/CD:

1. IaC GCP Foundation Provisioning: This dedicated pipeline utilizes GitHub Actions, Terraform Cloud, and Workload Identity to automate the provisioning of core GCP Folders, Projects and a shared Workload Identity project.

   

2. IaC GCP Projects Provisioning: Separate dedicated GitHub and Terraform for Dev, QA, UAT, and Prod workspaces, handle the creation and configuration of environment-specific projects using Terraform Cloud Workspaces. This ensures isolated environments while enabling controlled cross-environment access.

   

Backend and Frontend Deployment CI/CD:

1. Frontend Project (Cloud Storage Deployment): A separate GitHub project holds the HTML/CSS/JS code for my resume website. This pipeline, powered by GitHub Actions and Workload Identity, automates the deployment of website files to Cloud Storage, along with clearing the CDN cache.

   

2. Backend Project (Python Cloud Function API): A dedicated GitHub project houses the Python code for my backend API. This pipeline leverages GitHub Actions and Workload Identity to automate the CI/CD process for the API.

By embracing automation and exceeding the challenge requirements, This, align with the "DevOps Mod: Automation Nation."

Solutions Approach and Project Resource Breakdown

This breakdown organizes the resources used in our Cloud Resume project by component and its role:

1. Frontend:

   • HTML5, CSS3: Write a simple HTML code with CSS and add a popup Modal to give more details in project Design section.

   • Cloud Storage: Hosting Static Website content on Google Cloud Storage (Multi-region bucket), managing bucket creation, versioning, and public access configs.

   • Content Delivery Network (CDN):

     • Primary CDN: Cloudflare (Provides rate limiting for Cloud Storage)

     • Secondary CDN: Google Cloud CDN Interconnect (Optimizes connectivity with Cloudflare)

   • Domain Name System (DNS):

     • DNS Provider: Cloud DNS

     • Security: DNSSEC

   • Cloud External HTTPS Load Balancer

Resume url : https://sm-resume.microworka.com/

2. Backend Technologies:

   • Firestore Datastore Mode: Database to stores visitor count

   • Cloud Function (2nd Generation): Python 3.12 function to save visitor cloud to Database

   • Google Cloud API Gateway: Used to save visitor count and restricts access)

   • Google API Service API Keys Credentials: Restrict access to resume API Gateway URL

3. Bridging the Gap: Frontend and Backend Integration in Your Cloud Resume

   Your Cloud Resume project seamlessly connects the frontend and backend, demonstrating your grasp of web development concepts.

   • Javascript: leveraging communication witn frontend and backend

   • Cypress: Tool for running smoke tests

This combined approach, leveraging Javascript for communication witn frontend and backend and Cypress for testing, establishes a robust and well-tested connection between your Cloud Resume's frontend and backend, ensuring a flawless user experience.

4. Security: Essential Services and Best Practices used

   In today's digital landscape, securing your cloud environment is paramount. For our Cloud Resume, we take security very seriously. This dives into the essential services and best practices we leverage to build a robust and secure it.

   Core Security Services:

   • Guarding Against Misconfigurations: Checkov, a policy-as-code tool, continuously scans our infrastructure configurations for security vulnerabilities. By proactively identifying misconfigurations, we prevent security weaknesses before deployment.

   • Proactive Web App Security: Google Cloud Web Security Scanner plays a vital role in safeguarding our web applications. It actively hunts for security vulnerabilities, allowing us to address them before malicious actors can exploit them.

   • Centralized Security Command Center: Maintaining a holistic view of our GCP security posture is crucial. Google Cloud Command Security Center offers a unified platform that aggregates findings from various security tools. This centralized view empowers us to prioritize and efficiently remediate security threats.

   • Granular Access Control with IAM: Identity and Access Management (IAM) is the cornerstone of access control in GCP. IAM allows us to define user groups, service accounts, and their specific permissions for various GCP resources. This ensures only authorized entities can access resources, and only with the necessary permissions (read, write, etc.).

   • DNSSEC: Tamper-Proof DNS: Domain Name System Security Extensions (DNSSEC) adds a crucial layer of security to our DNS infrastructure. By cryptographically authenticating DNS records, DNSSEC safeguards against DNS spoofing attempts.

   • Seamless SSL/TLS Management: For secure communication between web applications and users, we rely on Certificate Manager. This service simplifies the process of issuing and managing SSL/TLS certificates for our GCP resources.

   • Simplified Workload Identity Management: The Centralized Workload Identity Federation Project streamlines how workloads running on GCP authenticate to external services. This eliminates the need to manage individual credentials for each workload, enhancing security and manageability.

   • Cloud Storage with Granular Access: Cloud Storage bucket policies provide granular control over access to data stored in Google Cloud Storage. These policies define who can access a bucket and what actions they can perform, ensuring sensitive data remains protected.

     

Least Privilege:

A fundamental security principle we adhere to is the principle of least privilege. This means all service accounts used by our services are granted only the minimum set of permissions required to fulfill their designated tasks. This minimizes the potential attack surface and reduces the risk of unauthorized access in case of a compromised service account.

5. Automating Cloud Resume: CI/CD and IaC

   • Continuous Integration/Continuous Deployment (CI/CD): Implemented GitHub Actions for automated testing (Cypress), build, and deployment processes across multiple environments (dev, QA, UAT, prod).

   • Infrastructure as Code (IaC): Utilized Terraform and Terraform Cloud for provisioning and managing GCP resources ans state, including projects, networking, security, and IAM configurations, with separate workspaces for each environment.

Taking Cloud Resume project and treating it as an enterprise-level project to improve skills and experience can be Good to prepare your selve to potential challenge!

6. Keeping an Eye on Your Cloud Resume: Monitoring and Alerting

   A crucial aspect of any well-managed cloud application is monitoring. Your Cloud Resume project demonstrates an understanding of this concept by incorporating three key tools:

   • Cloud Monitoring: Acts as a vigilant guardian, providing real-time insights into the health and performance of your Cloud Resume infrastructure, defining Health Checks, SLOs tracked API Gateway, Cloud Storage network latencies, and uptime, allowing to identify areas for cost optimization.

   • Cloud Logging: Acts as the digital diary, recording all events and logs generated by your application.

   • PagerDuty: Serves as the alarm system. It integrates with Cloud Monitoring and triggers alerts when predefined thresholds are breached.

7. Bonus: Generative AI and Appointement

   By incorporating a conversational AI chatbot and appointment scheduling, my Cloud Resume goes beyond the traditional format, offering a more engaging and interactive experience for potential employers. This demonstrates willingness to embrace cutting-edge technologies and ability to leverage them to create a truly unique and effective resume.

   • Conversational AI with Dialogflow CX: Users can interact with the chatbot by asking questions about experience, skills, or certifications listed on your resume.

   • Appointment Scheduling with Google Calendar: Eliminates the need for back-and-forth emails or phone calls to schedule interviews, making the process more convenient for both me and the employer.

8. High Availability: Multi-region Cloud Storage buckets, Cloud CDN, HTTPS, and an external load balancer ensured resilience.

9. Security: Cloud Armor was initially considered, but Cloudflare was ultimately chosen for its rate limiting capabilities on Cloud Storage. Workload Identity Federation and IAM with least privilege access controls further bolstered security.

Aligning with the Google Cloud Architecture Framework

The Google Cloud Architecture Framework provides recommendations and best practices to help architects, developers, administrators, and other cloud professionals design and operate a secure, efficient, resilient, high-performance, and cost-effective cloud topology.

• System Design: Implemented a secure and highly available architecture with a clear separation of concerns (database, backend, frontend, security).

• Operational Excellence: Automated deployments using CI/CD pipelines ensure efficient management of workloads.

• Security and Compliance: Utilized IAM, DNSSEC, Certificate Manager, Web Security Scanner, Security Command Center and Cloud Storage bucket policies for robust security.

• Reliability: Employed Cloud Storage Multi-region, Firestore, Cloud Load Balancing, and Cloud DNS for a resilient and available application.

• Cost Optimization: Leveraged serverless provisioning with Terraform to minimize costs, along with budget alerts and SLOs.

• Performance Efficiency: Optimized content delivery with Cloud CDN and fine-tuned cloud resources for optimal performance.

This experience showcased my ability to not only grasp complex cloud concepts but also translate them into a secure, scalable, and feature-rich cloud solution.

The Cloud Resume Challenge: Mission Accomplished, This project pushed me to confront challenges, learn from mistakes !

Challenges and Overcoming Them

Setting up a GCP Foundation Organization and a robust deployment strategy proved to be hurdles. Additionally, integrating Cloud Armor for DDoS protection required alternative solutions like Cloudflare with Cloud DNS. The backend initially lacked a separate endpoint for uptime checks. To address this, I plan to migrate to Cloud Run for improved deployment strategies.

Resume url : https://sm-resume.microworka.com/

Lessons and Challenges Learned

This project proved to be an invaluable learning experience, highlighting several key insights and challenges:

1. Strong Foundation: A solid understanding of cloud architecture principles is paramount. This project reinforced the importance of having a comprehensive grasp of GCP services and how they interact(Optimize GCP Landing Zone to meet my need with cost optimization by removing unecessarice service like VPC Sharing…).

2. Hands-on Practice: While certifications provided a theoretical base, this practical application was crucial for truly internalizing cloud concepts. The challenge of building a real-world application bridged the gap between theory and practice.

3. Automation is Key: Implementing DevOps practices, particularly CI/CD pipelines, significantly streamlined deployments and maintenance. This experience emphasized the efficiency gains from automation in cloud environments.

4. Security as a Priority: The project underscored the critical nature of implementing security measures. From IAM policies to HTTPS implementation, each security decision proved vital in creating a production-ready application.

5. Environment-Specific Deployments: Utilizing separate environments (Dev, QA, UAT, Prod) and leveraging Git's Fast-Forward Merge principle for deployments was enlightening. This approach ensured controlled, systematic rollouts and easier troubleshooting.

6. Adapting to Limitations: The challenge with implementing Cloud Armor for Cloud Storage as a backend service was a valuable lesson in flexibility. Pivoting to Cloudflare as an alternative solution because of issue with rate-limit with cloud armor, demonstrated the importance of being adaptable and finding creative workarounds in cloud architecture.

7. Cost Management: Balancing performance with cost-efficiency was an ongoing challenge. It highlighted the importance of continuous monitoring and optimization of cloud resources.

8. Documentation is Crucial: Maintaining clear, up-to-date documentation throughout the project proved essential, especially when troubleshooting issues or onboarding new features.

9. Community Support: Engaging with the cloud community, through forums and social media, provided invaluable insights and solutions to challenges encountered during the project.

Overcoming Specific Challenges:

1. Multi-Environment Setup: Initially, configuring distinct environments posed a challenge. I overcame this by thoroughly studying GCP's resource hierarchy and implementing a clear naming convention and access policies for each environment.

2. CI/CD Pipeline Complexity: Setting up a robust CI/CD pipeline that worked across all environments was initially daunting. I tackled this by starting with a basic pipeline and incrementally adding complexity, thoroughly testing at each stage.

Resume are in the Cloud Now, Looking Ahead: The Next Steps

My cloud resume is a stepping stone, not a destination. I plan to continuously improve it while optimizing costs. This blog post serves as just one way I'm sharing my knowledge. I intend to conttinous posting on this blogs and share knowledge with this Youtube channel Youtube Channel to empower others on the cloud journeys, including cost-effective practices.

Resume url : https://sm-resume.microworka.com/

Conclusion

My transformation from software developer to aspiring Multi-cloud architect is a testament to continuous learning and a passion for technology. The Cloud Resume Challenge provided a project to challenge my skills, and I'm confident it will be a valuable asset in my next step.

Are you seeking a seasoned professional for roles such as:

• Cloud & DevOps Engineer

• Cloud Platform Engineer

• Cloud Solutions Architect

• Cloud Architect

• Cloud Technology Evangelist

• Multi-Cloud & DevOps Engineer

• Multi-Cloud Technology Evangelist

• Cloud Automation Engineer

I offer a combination of skills and experiences:

• 9+ years in software development with extensive cloud expertise across GCP and Azure with knowlege on OCI, and AWS

• 15+ cloud certifications, including Google Cloud, Azure, Databricks, Aviatrix, and Oracle Cloud

• Proven track record of architecting and implementing secure, scalable cloud solutions

• Strong background in DevSecOps, infrastructure automation, and Generative AI integration

• Experience in optimizing cloud costs and improving operational efficiency

• Passion for innovative business solutions and continuous learning in cloud technologies

My goal is to leverage this diverse skill set to drive organization's cloud transformation, enhance security posture, and accelerate time-to-market. I'm particularly adept at:

• Designing and implementing multi-cloud architectures

• Optimizing DevOps processes and CI/CD pipelines

• Integrating cutting-edge technologies like Kubernetes and Generative AI

• Ensuring robust cloud security and compliance

Let's connect and explore how my expertise in cloud architecture, DevOps, and emerging technologies can add significant value to your team and drive your cloud initiatives forward https://www.linkedin.com/in/merlin-saha/

Understanding True Multi-Cloud:

What Multi-Cloud Isn't

• Running different workloads on different clouds without integration

• Having multiple disconnected cloud accounts across departments

• Using SaaS solutions from various providers without a unified strategy

What Multi-Cloud Should Be

• A deliberate architectural approach leveraging each cloud's strengths

• An integrated ecosystem with seamless data and application flow

• A unified governance and management framework across providers

The Strategic Advantages of Multi-Cloud

1. Best-of-Breed Solutions

Modern enterprises require diverse capabilities that no single cloud provider can fully deliver. A strategic multi-cloud approach allows organizations to:

• Leverage AWS's extensive service ecosystem for microservices

• Utilize Google Cloud's superior AI/ML capabilities

• Take advantage of Azure's deep integration with Microsoft enterprise tools

• Access Oracle's high-performance database solutions across clouds

Real-world example: MongoDB Atlas deployments across AWS, Azure, and Google Cloud provide high availability with workload isolation while maintaining consistent performance across regions.

2. Enhanced Enterprise Resilience

Multi-cloud architectures provide natural redundancy and disaster recovery capabilities:

• Geographic distribution of workloads

• Provider-level failover options

• Reduced impact from regional outages

• Enhanced business continuity planning

Example: Oracle Database availability on both Microsoft Azure and Google Cloud ensures critical workloads remain operational even during provider-specific incidents.

3. Strategic Flexibility

A well-implemented multi-cloud strategy offers:

• Negotiating leverage with providers

• Ability to switch workloads between clouds

• Optimization of costs across providers

• Freedom to choose best-fit services for each requirement

Essential Building Blocks for Multi-Cloud Success

1. Connectivity Solutions

Modern multi-cloud architectures require robust interconnection:

• Direct Connections:

  • Google Cloud Dedicated Interconnect

  • Google Cloud Cross-Cloud Interconnect

  • Azure ExpressRoute

  • Oracle FastConnect

  • AWS DirectConnect

• Network Orchestration:

  • Aviatrix Multi-Cloud Network Architecture

  • Software-defined networking across clouds

  • Unified security policies

• CPS Multi-cloud & Hybrid Services

  • Google Cloud Anthos

  • AWS Outposts

  • Azure Arc

  • Azure Stack

  • VMWare

2. Automation and Infrastructure as Code

Successful multi-cloud management requires sophisticated automation:

# Example Terraform configuration for multi-cloud
provider "aws" {
  region = "us-west-2"
}

provider "azurerm" {
  features {}
}

provider "google" {
  project = "my-project"
  region  = "us-central1"
}

# Cross-cloud resource management

Key components:

• Terraform for infrastructure provisioning

• GitHub Actions for CI/CD pipelines

• Terraform Cloud for state management

• Custom scripts for cross-cloud orchestration

3. Security and Governance

Critical considerations for multi-cloud security:

• Identity and Access Management (IAM) across clouds

• Consistent security policies and compliance

• Centralized logging and monitoring

• Regular security audits and assessments

Implementation Best Practices

1. Strategic Planning

• Begin with clear business requirements

• Define specific criteria for workload placement

• Create a detailed migration roadmap

• Establish KPIs for success measurement

2. Technical Architecture

• Design for interoperability

• Implement consistent naming conventions

• Plan for data sovereignty requirements

• Consider latency between cloud providers

3. Operational Excellence

• Develop cross-cloud monitoring strategies

• Implement centralized logging

• Create unified incident response procedures

• Maintain documentation and training programs

Common Challenges and Solutions

1. Cost Management

• Implement cloud cost management tools

• Regular cost optimization reviews

• Clear chargeback mechanisms

• Budget alerts and monitoring

2. Skill Gaps

• Training programs for team members

• Partnerships with cloud experts

• Documentation and knowledge sharing

• Regular skill assessment and development

3. Complex Operations

• Automated operational procedures

• Clear escalation paths

• Defined responsibility matrices

• Regular operational reviews

Measuring Multi-Cloud Success

Key metrics to track:

1. Technical Metrics:

   • Cross-cloud latency

   • Service availability

   • Recovery time objectives

   • Performance benchmarks

2. Business Metrics:

   • Cost optimization

   • Time-to-market improvements

   • Resource utilization

   • Innovation enablement

Future Trends in Multi-Cloud

Emerging developments to watch:

• Edge computing integration

• AI-driven cloud orchestration

• Enhanced cross-cloud services

• Improved standardization

Conclusion

A successful multi-cloud strategy requires careful planning, robust architecture, and continuous optimization. While the journey may seem complex, the benefits of increased flexibility, resilience, and innovation potential make it worthwhile for many organizations. Remember: multi-cloud should never be adopted simply because it's trendy – it must align with specific business needs and capabilities.

Last updated: November 2024

Resources to get started

• Multi-Cloud Automation Azure, AWS, GCP with Terraform Cloud and CI/CD on GitHub Actions

• Building a Global E-commerce Empire - Anthos Multi Cloud for Zero Downtime Scale on GCP & AWS

#multicloud #cloudcomputing #innovation #automation #devops

Workload Identity Federation is a feature in GCP that allows you to securely authenticate to GCP services without needing to manage service account keys. Instead, you can use a Google Cloud identity (such as a service account) to grant access to your GitHub Actions workflow, and GCP will automatically authenticate the workflow based on the configured identity.

Here's how to set it up:

1. Create Workload Identity Federation Pool and Provider in GCP

   • Go to the IAM & Admin section and click on Workload Identity Federation in the GCP Console and click on "CREATE POOL".

     

   • Create an identity pool: Specify the required information and click on "CONTINUE"

     

   • Add a provider to pool: select OpenID Connect (OIDC) in Select a provider and add https://token.actions.githubusercontent.com in Issuer (URL)

     

   • Configure provider attributes as like this:

       google.subject = assertion.sub
       attribute.repository = assertion.repository
     

   • Save the pool andprovider

     

2. Create a Google Cloud service account

• Go to the Service Accounts section in the GCP Console.

• Click "Create Service Account."

• Provide a name for the service account (e.g., "github-actions-sa").

• Optionally, you can add a description.

• Click "Create and Continue."

• On the next screen, skip granting roles for now, and click "Done."

  

3. Grant required role to Google Cloud service account

    roles/iam.workloadIdentityUser
   
    # And Add Annother Role your need to specific task, eg:
    roles/artifactregistry.writer
   

   

   Click on "DONE"

4. UpdateWorkload Identity Federation to add service github-actions-sa@<project_id>.iam.gserviceaccount.com

   Click on GitHub Actions Display Name

   

   And Click Grant Access

   

   Add your SA email

   

   Add your GitHub Repository like this: github_account/github_repository and Click on "SAVE" in the popup page, click on DISMISS

   

   Your provider CONNECTED SERVICE ACCOUNTS should look like this

   

5. Use Workload Identity Federation in your GitHub Actions workflow

   Copy Pool ID and Provider ID in Workload Identity Federation in this case is github-actions and github-actions-provider

   

• In your GitHub repository, create a new workflow file (e.g., .github/workflows/upload.yml).

• In the workflow file, add the following step to authenticate with GCP using Workload Identity Federation: change <GCP_PROJECT_NUMBER> and <GCP_PROJECT_ID>

          - id: 'auth'
            name: 'Authenticate Google Cloud'
            uses: 'google-github-actions/auth@v1'
            with:
              create_credentials_file: true
              workload_identity_provider: 'projects/<GCP_PROJECT_NUMBER>/locations/global/workloadIdentityPools/github-actions/providers/github-actions-provider'
              service_account: 'github-actions-sa@$<GCP_PROJECT_ID>.iam.gserviceaccount.com'
  

  Replace the workload_identity_provider value with the one you configured in step 3, and the service_account value with the email address of the service account you created in step 2.

• After the authentication step, you can use the authenticated context to interact with GCP services, such as deploying to Cloud Run, uploading files to Cloud Storage, or running commands on Compute Engine instances

Full code exemple: https://github.com/devsahamerlin/employees-managements-api

Congratulations! By using Workload Identity Federation, you no longer need to manage and rotate service account keys manually. GCP will automatically authenticate your GitHub Actions workflow based on the configured identity, providing a more secure and convenient way to authenticate to GCP services.

Note that, this is a high-level overview of the process, and you may need to adjust the configuration based on your specific requirements and GCP project setup.

Service and Tools Used:

Cloud Source Repositories: It's a cloud-based source code management service provided by GCP. It provides a private and secure Git version control repository to store and manage source code versions of our projects, Disadvantage: Lack of PR or MR option;

Cloud Build: It's a continuous integration (CI) service provided by GCP. It allows to build, test, analyze and deploy applications on GCP using build and deployment workflows that we can configure according to our needs.

Cloud build Trigger: It's an event trigger that allows to automatically launch a build process in Cloud Build in response to a specific event such as the creation or modification of a file in a source repository or a new container image added to a container registry.

Artifact Registry: It's a cloud-based package storage service provided by GCP. It allows developers to store, manage and distribute packages such as JAR files, Python libraries and Docker images in a secure private repository.

IAM: Identity and access management service to manage permissions and roles.

Container Scanning API: It allows you to analyze container images stored in a private Artifact Registry repository to identify known security vulnerabilities. The service regularly scans the images stored in the repository to detect known vulnerabilities in the packages, libraries, and dependencies included in the container image.

Container Analysis API: It's a service offered by Google Cloud Platform (GCP) that allows you to analyze container images stored in Google Artifact or Container Registry or other compatible container registries.

Binary Authorization: Is a GCP service that allows you to verify and authorize container deployments in a GCP environment;

Google Kubernetes Engine (GKE): It's a cloud-based containerization service provided by Google Cloud Platform (GCP). It allows you to deploy, manage, and orchestrate Docker containers at scale on GCP.

Backup for GKE (Google Kubernetes Engine): Backup for GKE is a data backup service for Kubernetes clusters running on GKE, allowing users to protect their applications from data loss and simplify migration between clusters.

Cloud Deploy: It's a continuous deployment (CD) service that simplifies and automates the process of deploying applications on GCP.

Cloud Functions: Serverless platform for executing code on demand. Example: deploying notification email sending functions with node Js;

Cloud Storage: Object storage service to store and manage files.

Operations Suite: GCP Logging and Monitoring or monitoring and logging toolset for managing logs and alerts. Pub/Sub receives events published by Cloud Deploy and allows Cloud Functions to send notification emails to teams as needed (Notifications, Approve, Canary Step Progress);

Static IP Address: This is a fixed and persistent Internet IP address assigned to a resource hosted on Google Cloud Platform, which is publicly accessible on the Internet, typically used for resources such as virtual machine instances, load balancers or VPN gateways that need a persistent and publicly accessible IP address for clients to access them. Example: we use it for the load balancer on our different environments;

Google Cloud Load Balancer or load balancers: it is a load distribution service for managing network traffic. Example: Allow external Applications to interact with our service from an external Static IP address;

Pub/Sub: it's an asynchronous messaging service offered by GCP. It allows applications to communicate with each other by publishing and subscribing messages to "topics", which can be thematic broadcast channels.

KMS (Key Management Service): it's an encryption key management service offered by GCP. It allows you to create, store, manage and use encryption keys to protect data stored in the cloud. Example: store image keys to allow binary authorizations to verify containers before deployment;

Compute Engine: Google Compute Engine (GCE) is a cloud computing service offered by Google that allows users to rent virtual machines (VMs) on their cloud infrastructure. Example, in order not to use SonarCloud, we will use it to deploy Sonarqube;

Sonarqube: is an open-source platform for code quality management and static code analysis. It allows development teams to verify the quality of source code, detect security issues, identify potential bugs and measure code coverage;

Ansible: Ansible is an open-source configuration management, deployment automation and system orchestration tool. It allows you to centrally manage the configuration and deployment of a large number of machines, whether physical, virtual or in the cloud;

Docker Compose: Docker Compose is an open-source Docker container management tool. It allows you to define, configure and launch multiple Docker containers at the same time, using a YAML file to describe all the necessary services and configurations.

Check PoC video here in French

These strategies, combined with GCP's auto-scaling, load balancing, and traffic splitting capabilities, ensure a smooth, low-risk transition to newer application versions.

By embracing DevSecOps principles and leveraging GCP's powerful services, organizations can achieve faster time-to-market, improved security and compliance, and enhanced application resilience, enabling them to stay ahead in the competitive digital landscape.

If you prefer French, check PoC video here

Prerequisites:

• A GCP project

• A Terraform Cloud account and workspace

Step 1: Enable Required GCP APIs First, you need to enable the required APIs in your GCP project:

gcloud services enable iamcredentials.googleapis.com
gcloud services enable cloudresourcemanager.googleapis.com

Step 2: Create a Google Cloud Workload Identity Pool: It's a collection of workloads that share the same identity and access policy. Create one with:

gcloud iam workload-identity-pools create tfc-wif-pool \
  --project=<PROJECT_ID> \
  --location=global

Step 3: Create a Google Cloud Workload Identity Pool Provider: This links your external identity provider (in this case Terraform Cloud) to the workload identity pool:

gcloud iam workload-identity-pools providers create-oidc tfc-wif-provider \
  --project=<PROJECT_ID> \
  --location=global \
  --workload-identity-pool=tfc-wif-pool \
  --issuer-uri=https://app.terraform.io \
  --attribute-mapping="google.subject=assertion.terraform_workspace_id"

Step 4: Create a Google Service Account for Terraform: This represents the identity that Terraform will use:

gcloud iam service-accounts create tfc-wif-sa \
  --project=<PROJECT_ID>

Step 5: Allow the Service Account to user the Workload Identity:

gcloud projects add-iam-policy-binding <PROJECT_ID> \
    --member serviceAccount:tfc-wif-sa@<PROJECT_ID>.iam.gserviceaccount.com \
    --role roles/iam.workloadIdentityUser

Step 6: Add Permissions to the Service Account and any required permissions to the service account, such as the ability to create and manage compute Engine resources:

gcloud projects add-iam-policy-binding <PROJECT_ID> \
  --member="serviceAccount:tfc-wif-sa@<PROJECT_ID>.iam.gserviceaccount.com" \
  --role="roles/compute.admin"

Step 7: Configure Terraform Cloud In your Terraform Cloud workspace:

1. Go to "Variables" and create a new environment : change PROJECT_NUMBER and PROJECT_ID

    TFC_GCP_PROJECT_NUMBER = <PROJECT_NUMBER> 
    TFC_GCP_PROVIDER_AUTH = true    
    TFC_GCP_RUN_SERVICE_ACCOUNT_EMAIL = tfc-wif-sa@<PROJECT_ID>.iam.gserviceaccount.com
    TFC_GCP_WORKLOAD_POOL_ID = tfc-wif-pool
    TFC_GCP_WORKLOAD_PROVIDER_ID = tfc-wif-provider
   

   

2. UpdateWorkload Identity Federation to add service tfc-wif-sa@<PROJECT_ID>.iam.gserviceaccount.com

   Click on tfc-wif-pool Display Name

   

3. And Click Grant Access

   

4. Add your SA email

   

   Add your Terraform cloud Workspace ID like this:

   Copy your **ws-**xSSKSSSSSS

   

5. Update subject with the workspace ID subject and Click on "SAVE" in the popup page, click on DISMISS

   

6. Your provider CONNECTED SERVICE ACCOUNTS should look like this

   

7. create a terraform file main.tf, add the google provider block and resource to create Compute Engine Instance:

terraform {
  cloud {
    organization = "change_me" # change this

    workspaces {
      name = "tfc-gcp-wif"
    }
  }
}

provider "google" {
  project = var.gcp_project_id
  region  = var.gcp_region
  zone    = var.gcp_zone
}

variable "gcp_project_id" {}

variable "gcp_region" {
  default = "us-east4"
}

variable "gcp_zone" {
  default = "us-east4-c"
}

resource "google_compute_instance" "test-instance" {
  name         = "test-instance"
  machine_type = "n1-standard-1"
  zone         = var.gcp_zone

  boot_disk {
    initialize_params {
      image = "centos-cloud/centos-7"
      size = 20
    }
  }

  network_interface {
    subnetwork = "default"
  }
}

Run terraform init, terraform plan and terraform apply --auto-approve

Congratulations, you did it !

That's it! Terraform Cloud can now securely provision resources in your GCP project using Workload Identity Federation without needing to manage long-lived service account keys. The service account permissions can be scoped as needed, and the external identity is validated by GCP for each run.

Don't forget to destroy ressources !

If you prefer French, you can watch the video version here

Step 1: Set up Terraform Cloud

1. Sign up for a Terraform Cloud account (https://app.terraform.io/signup/account)

2. Create a new organization

   

3. Create a terraform Projects

   

4. Create a new workspace: you need to choose the best option for your use case (just read each option description), here we will choose CLI-Driven Workflow

   

Step 2: Set up MongoDB Atlas

1. Sign up for a Terraform Cloud account (https://account.mongodb.com/account/login

2. Create a new organization

   

   

3. In the MongoDB Atlas Organization, on "Settings" section, copy Organization ID

   

4. In Organization "Access Manager" section, create API Key With Public and Private key

   

5. Provide the required permission to the API Key

   

6. Allow your IP CIDR to access MongoDB Atlas your-ip/32

   

7. Copy and save API Public and Private Key Information, we will use it on Terraform Cloud.

   

Step 3: Integrate MongoGB Atlas with Terraform Cloud

Configure variables and environment variables in Terraform Cloud, with your MongoDB Atlas credentials (API key, Organization ID, etc.)

Step 4: Configure Terraform for MongoDB Atlas

1. Install Terraform on your local machine (https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli)

2. Add the MongoDB Atlas provider to your Terraform configuration file (e.g., main.tf)

    # main.tf
    provider "mongodbatlas" {
      public_key = var.mongoDB_Atlas_Public_Key
      private_key  = var.mongoDB_Atlas_Private_Key
    }
   
    # variable.tf
    variable "mongoDb_Atlas_Public_Key" {
        description = "Public Key to add on Terraform Cloud"
    }
   
    variable "mongoDb_Atlas_Private_Key" {
        description = "Private Key to add on Terraform Cloud"
    }
   

3. In terraform cloud namespace click on "Overview" and copy the terraform code

   

4. Update main.tf and add terraform cloud namespace, with the code copied

    # main.tf
    terraform {
      cloud {
        organization = "devsahamerlin"
   
        workspaces {
          name = "mongodb-atlas"
        }
      }
    }
   

5. Add MongoDB Atlas Version

    terraform {
      cloud {
        organization = "devsahamerlin"
   
        workspaces {
          name = "mongodb-atlas"
        }
      }
      required_providers {
        mongodbatlas = {
          source  = "mongodb/mongodbatlas",
          version = "1.8.0"
        }
      }
    }
   

6. Your Complete main.tf in this step will look like this

    # main.tf
    terraform {
      cloud {
        organization = "devsahamerlin"
   
        workspaces {
          name = "mongodb-atlas"
        }
      }
      required_providers {
        mongodbatlas = {
          source  = "mongodb/mongodbatlas",
          version = "1.8.0"
        }
      }
    }
   
    provider "mongodbatlas" {
      public_key = var.mongoDb_Atlas_Public_Key
      private_key  = var.mongoDb_Atlas_Private_Key
    }
   
    variable "mongoDb_Atlas_Public_Key" {
        description = "Public Key to add on Terraform Cloud"
    }
   
    variable "mongoDb_Atlas_Private_Key" {
        description = "Private Key to add on Terraform Cloud"
    }
   

7. Run terraform login to connect to terraform cloud

    terraform login
   

   

8. Initialize a new Terraform configuration by running terraform init

   

Step 5: Define MongoDB Atlas Resources

1. Use the Terraform MongoDB Atlas provider to define the resources you want to create (e.g., projects, clusters, database users, etc.)

2. Write the resource definitions in your Terraform configuration main.tf file(s)

    resource "mongodbatlas_project" "project" {
      name   = "meanstack"
      org_id = var.mongogb_atlas_org_id
   
      is_collect_database_specifics_statistics_enabled = true
      is_data_explorer_enabled                         = true
      is_performance_advisor_enabled                   = true
      is_realtime_performance_panel_enabled            = true
      is_schema_advisor_enabled                        = true
    }
   

   We add new variables mongogb_atlas_org_id, let's update terraform cloud variable

   

Step 4: Plan and Apply the Changes

Terraform provides two crucial commands for managing infrastructure changes: plan and apply. Your terraform main.tf file should look like this now:

# main.tf
terraform {
  cloud {
    organization = "devsahamerlin"

    workspaces {
      name = "mongodb-atlas"
    }
  }
  required_providers {
    mongodbatlas = {
      source  = "mongodb/mongodbatlas",
      version = "1.8.0"
    }
  }
}

provider "mongodbatlas" {
  public_key = var.mongoDb_Atlas_Public_Key
  private_key  = var.mongoDb_Atlas_Private_Key
}

variable "mongoDb_Atlas_Public_Key" {
    description = "Public Key to add on Terraform Cloud"
}

variable "mongoDb_Atlas_Private_Key" {
    description = "Private Key to add on Terraform Cloud"
}

variable "mongogb_atlas_org_id" {
    description = "MongoDB Atlas organization ID"
}

resource "mongodbatlas_project" "project" {
  name   = "meanstack"
  org_id = var.mongogb_atlas_org_id

  is_collect_database_specifics_statistics_enabled = true
  is_data_explorer_enabled                         = true
  is_performance_advisor_enabled                   = true
  is_realtime_performance_panel_enabled            = true
  is_schema_advisor_enabled                        = true
}

1. Run terraform plan to preview the changes Terraform will make

   This command analyzes your Terraform configuration files and compares them to the existing infrastructure (if any) managed by Terraform. It then generates a detailed plan outlining the actions Terraform will take to achieve the desired state defined in your configuration. The plan will typically show:

   • Resources to be created

   • Resources to be modified (attributes changing)

   • Resources to be destroyed (if present)

2. Review the plan output and ensure everything looks correct

   

3. Run terraform apply to create the MongoDB Atlas resources

   Once you've reviewed and approved the plan generated by terraform plan, you can use the apply command to execute the planned actions. This will create, modify, or destroy resources as outlined in the plan.

   Important points aboutapply:

   • Irreversible changes: Applying the plan makes permanent changes to your infrastructure. Make sure you understand the plan and have backups before proceeding.

   • Confirmation prompt: By default, apply will prompt you for confirmation before making any changes.

if you get error while applying , make sure your IP address is added to Error: error creating Project: POSThttps://cloud.mongodb.com/api/atlas/v1.0/groups: 403 (request "IP_ADDRESS_NOT_ON_ACCESS_LIST") IP address your_ip is not allowed to access this resource.

4. Verify that your ressource is avaible on MongoDB Atlas

   

Step 5: Destroy MongoDB Atlas Resources

After you've finished working with the MongoDB Atlas resources created using Terraform, you can destroy them to avoid incurring unnecessary costs. Here's how:

1. Run terraform plan -destroy to see which resources will be destroyed

2. Review the plan output to ensure you're destroying the correct resources

3. Run terraform destroy to destroy all the MongoDB Atlas resources you created

4. Terraform will prompt you to confirm the destruction of resources

5. Type "yes" and press Enter to confirm

It's important to note that the terraform destroy command will permanently delete all the resources defined in your Terraform configuration. Make sure to back up any important data before running this command.

You can also trigger a "Destroy" run from the user interface to destroy the resources managed by your workspace.

Congratulations !

Using Terraform and Terraform Cloud for managing MongoDB Atlas resources offers several key benefits and advantages:

1. Infrastructure as Code: Terraform allows you to define your MongoDB Atlas resources as code, making it easier to manage, version, and collaborate on your infrastructure configurations.

2. Version Control: By storing your Terraform configurations in a version control system like Git, you can track changes, revert to previous states, and collaborate with team members more effectively.

3. Automated Workflows: Terraform Cloud enables automated workflows for provisioning and managing your MongoDB Atlas resources. You can trigger runs based on various events, such as code changes or scheduled intervals, streamlining the deployment process.

4. Collaboration and Governance: Terraform Cloud provides features for team collaboration, including access controls, policy enforcement, and centralized management of Terraform configurations and state files.

5. Consistency and Reproducibility: With Terraform, you can ensure consistent and reproducible deployments of your MongoDB Atlas resources across different environments (development, staging, production), reducing the risk of configuration drift.

6. Resource Lifecycle Management: Terraform not only provisions resources but also manages their lifecycle. You can easily update or destroy resources as needed, ensuring efficient resource management and cost optimization.

7. Multi-Cloud and Multi-Provider Support: While this blog post focuses on MongoDB Atlas, Terraform supports a wide range of cloud providers and services, making it a versatile tool for managing your entire infrastructure.

By leveraging Terraform and Terraform Cloud for managing MongoDB Atlas resources, you can benefit from a streamlined, version-controlled, and collaborative approach to infrastructure provisioning and management. This not only improves efficiency and consistency but also enables better governance, compliance, and cost optimization for your MongoDB Atlas deployments.

Introduction

We'll walk through the tools to set up an automated secure CI/CD pipeline for Oracle Cloud Infrastructure (OCI) using popular DevSecOps tools and techniques. We'll explore two deployment choices: one on Oracle Cloud Virtual Machines and the other on Kubernetes installed on Oracle Cloud Virtual Machines. Additionally, we'll leverage Terraform, Ansible and Bash scripts to automate the provisioning and configuration of the required infrastructure and tools and Argo CD for Deployment.

Technologies Used:

1. Jenkins: An open-source automation server that facilitates Continuous Integration and Continuous Deployment (CI/CD) processes.

2. OWASP Dependency-Check: A utility that identifies project dependencies and checks for known, publicly disclosed vulnerabilities.

3. Trivy: A simple and comprehensive vulnerability scanner for containers and other artifacts, suitable for CI/CD pipelines.

4. SonarQube: A platform for continuous code quality analysis, providing insights into code quality, security vulnerabilities, and technical debt.

5. Oracle Autonomous Database: A fully managed, preconfigured database environment that is designed to provide high performance, high availability, and automated patching and upgrades.

6. Virtual Cloud Network (VCN): OCI's software-defined networking service that provides connectivity between resources in the cloud.

7. Compartment: A logical container in OCI for isolating and controlling access to resources.

8. Security Group: A virtual firewall that controls inbound and outbound traffic at the instance level in OCI.

9. Maven: A build automation tool used primarily for Java projects, managing dependencies and building and packaging applications.

10. GitHub: A web-based version control and collaboration platform for software development.

11. Docker: An open-source platform for building, shipping, and running applications in containers.

12. Docker Hub: A cloud-based registry service for storing, distributing, and managing Docker container images.

13. ArgoCD: A declarative continuous delivery tool for Kubernetes applications.

14. Kubernetes: An open-source container orchestration system for automating deployment, scaling, and management of containerized applications.

15. Terraform: An infrastructure-as-code (IaC) tool that allows you to provision and manage cloud resources using a declarative configuration language.

16. Ansible: An open-source IT automation tool that automates software provisioning, configuration management, and application deployment.

17. Bash Scripts: Shell scripts written in the Bash scripting language for automating various tasks.

Check PoC video here in French

Step 1: Provision Infrastructure using Terraform

1. Use Terraform to provision the required infrastructure resources in OCI, including:

   • Virtual Cloud Network (VCN)

   • Subnets

   • Compute instances (for Jenkins, SonarQube, etc.)

   • Oracle Autonomous Database instance

   • Security groups

   • Compartments

   • Etc.

Step 2: Configure Jenkins(Agent and Master) on OCI, automically with Ansible Playbook and Bash Script

1. Install Java and Jenkins on the designated Compute instance.

2. Intall Kubernetes

3. Install Trivy on the Jenkins Compute instance.

4. Install Docker

5. Configure Jenkins Master and Ajent.

6. Deploy ArgoCD

Step 3: Integrate OWASP Dependency-Check

1. Install OWASP Dependency-Check on the Jenkins Compute instance.

2. Create a Jenkins pipeline job and add a stage to run OWASP Dependency-Check.

3. Configure OWASP Dependency-Check to scan your application's dependencies for known vulnerabilities.

Step 4: Integrate Trivy for Container Image Scanning

1. Add a stage in your Jenkins pipeline to scan the built container image using Trivy.

2. Configure Trivy to scan for vulnerabilities in the container image and its dependencies.

Step 5: Integrate SonarQube for Code Quality Analysis

1. Use Terraform to provision a SonarQube server on OCI.

2. Add a stage in your Jenkins pipeline to run SonarQube analysis on your code.

3. Configure SonarQube to analyze your code for bugs, code smells, and security vulnerabilities.

Step 6: Configure the CI/CD Pipeline

1. Define the stages in your Jenkins pipeline:

   • Checkout code from GitHub

   • Build the application using Maven

   • Run OWASP Dependency-Check

   • Build and scan the container image with Trivy

   • Run SonarQube analysis

   • Include a stage for building and pushing the container image to Docker Hub.

   • Add a stage in the pipeline to trigger ArgoCD deployment after successful pipeline execution.

   • Etc.

2. Configure Jenkins to trigger the pipeline automatically on code commits or manually as needed.

Step 6: Deployment Choice 1, Oracle Cloud Virtual Machines

1. Deploy the application on Oracle Cloud Virtual Machines

Step 7: Deployment Choice 2, Kubernetes on Oracle Cloud Virtual Machines

1. Configure ArgoCD to automatically deploy your application to the Kubernetes cluster based on the pipeline output.

Contratulations to have read till here !

Step 8: Source code

Source code here with a README file: https://github.com/devsahamerlin/iac-spring-boot-atp-jenkins-oci-devsecops

Video Link here in French: https://www.youtube.com/watch?v=mvBNh6scVHk

By following steps in video you will leveraging tools like Terraform, Ansible, and Bash scripts, to automate the provisioning and configuration of an end-to-end secure CI/CD pipeline for Oracle Cloud Infrastructure. This pipeline incorporates DevSecOps practices using popular tools like Jenkins, OWASP Dependency Check, Trivy, and SonarQube, ensuring that security is addressed throughout the entire software development lifecycle.

The deployment choices provided cater to different scenarios: the first choice deploys the application on Oracle Cloud Virtual Machines, while the second choice leverages Kubernetes for container orchestration and deployment on Oracle Cloud Virtual Machines. In both choices, all required resources, including Oracle Autonomous Database, are provisioned using the provided Terraform code.