DEV Community: Saurabh Ahuja

Why You Don’t Need GCP Credentials Anymore: Identity Is the New Perimeter

Saurabh Ahuja — Mon, 02 Feb 2026 01:24:45 +0000

For most of cloud computing’s history, access meant credentials. If a workload needed to talk to a cloud API, it was issued a key. If a pipeline needed permissions, a secret was injected. If automation needed elevated access, a service account was created and carefully guarded. This model felt natural. It mirrored how we authenticated users and machines for decades.

However, it was never meant for our planet. As cloud infrastructure has gotten more dynamic, ephemeral, and automated, long-lived credentials have silently become one of the weaknesses of modern systems. Industry has not responded by rotating or encrypting secrets faster. Instead, they were removed from the vital path.

The shift underway is subtle but profound: identity, not credentials, is becoming the security perimeter.

Credentials Were a Convenience, Not a Foundation

Static credentials solved an early problem: how to let software authenticate itself without a human in the loop. They assumed relatively stable environments, predictable lifecycles, and clear trust boundaries. Those assumptions no longer hold.

Modern infrastructure is defined by constant motion. Containers start and stop in seconds. CI/CD pipelines create short-lived workers on demand. Infrastructure is provisioned and modified continuously by automation. In this world, secrets behave poorly.

They leak through logs and misconfigurations. They sprawl across repositories and configuration files. They accumulate permissions over time because removing access is risky and inconvenient. Even when teams do everything “right,” credentials still represent static trust in a dynamic system.

The uncomfortable truth is this: credentials were a workaround, not an architectural endpoint. We tolerated them because we didn’t yet have a better abstraction. Now we do.

Identity Changes the Question Entirely

Identity-based security reframes access from the ground up. Instead of asking, “Do you have the right key?”, platforms ask a more meaningful question: “Who are you, what are you running as, and should you be allowed to do this right now?”

Identity is richer than a secret. It represents a workload, a runtime, or an automated system. It can be bound to policy, evaluated dynamically, and constrained by context. It can expire naturally without requiring manual intervention.

Most importantly, identity does not imply permanent trust. Zero-trust principles underpin this change, but it goes beyond security. It recognizes that modern systems require ongoing trust-building. When identity matters, access decisions aren't binary. Time-bound, contextual, and explicit.

Why Credentials Start to Disappear in Practice

Modern cloud platforms provide workload authentication without secrets. Federated identity and short-lived tokens replace keys.
The mechanics matter less than the outcome:

Tokens are issued only when needed.
They are scoped narrowly to a specific purpose.
They expire automatically.
They cannot be reused outside their intended context.

There is nothing to check into source control. Nothing to rotate on a schedule. Nothing to recover when compromised. The entire class of problems associated with secret hygiene simply vanishes.
Authentication moves out of application code and into the platform. Security becomes an infrastructure concern rather than a developer responsibility. This is not just more secure. It is more aligned with how cloud systems actually behave.

The Architectural Payoff Is Bigger Than Security

Although security drives it, identity-first access has architectural benefits.
CI/CD pipelines no longer inject build job secrets. The pipeline run can authenticate itself, gain temporary rights, and lose them after it finishes. This eliminates a major credential leakage source.
Containerized workloads no longer mount keys or config files containing secrets. Instead, each workload carries its own identity. Scaling up does not involve copying credentials; identity scales naturally with the system.

Infrastructure automation becomes cleaner as well. Provisioning tools authenticate through identity, receive exactly the permissions required for the operation, and relinquish them automatically. There is no need for long-lived, high-privilege keys floating through automation pipelines.

The result is infrastructure that is easier to reason about. Access paths are explicit. Failure modes are fewer. Audits map actions directly to identities rather than anonymous secrets. Security improves not by adding controls, but by removing fragile dependencies.

Identity as an Operational Simplifier

Operational simplicity is undervalued in this change. Routine rotation, expiration monitoring, emergency recovery, and access assessments are needed for credential-based systems. Each allows for failure and human mistake.

The platform handles complexity in identity-based systems. Automatic token expiration. Centrally enforced permissions. Revocation is policy change, not emergency key rotation. This greatly lowers operational noise. Teams focus less on access plumbing and more on system reliability. When anything goes wrong, the blast radius is narrower and the cause is clearer. This disparity compounds quickly in large environments.

This Is Ultimately a Human Story

Technology that adapts to human behavior succeeds or fails. Identity-first security works because humans are bad at scaling secrets. No developer should keep secrets. They should not need to understand key formats, rotation strategies, or storage mechanisms to build secure systems. When security depends on perfect human execution, it eventually fails.

Identity-based access flips the incentives. The safest path becomes the easiest path. Developers authenticate implicitly through the environments they run in. Security policies are enforced consistently, regardless of who wrote the code.
This alignment between usability and security is what allows identity-first systems to endure.

Common Misunderstandings About “No Credentials”

Saying “you don’t need credentials anymore” often triggers skepticism, and rightly so. Credentials do not disappear entirely; they move. Control planes still rely on strong authentication. Identity providers still use cryptographic trust. What changes is where credentials live and who manages them.

They are no longer scattered across workloads, pipelines, and configuration files. They are centralized, abstracted, and handled by systems designed for that purpose. Another misconception is that identity federation is only for large or highly regulated environments. In practice, smaller systems often benefit the most, because they eliminate an entire category of complexity early on.
The real risk lies in partial adoption, keeping old secrets “just in case.” This undermines the model and preserves the very risks identity-first designs are meant to eliminate.

Where This Is All Headed

The long-term trajectory is clear. Access to cloud infrastructure is becoming policy-driven, contextual, and temporary. Together with computing, storage, and networking, identity becomes a first-class primitive. In this future, secrets are an implementation detail, not an architectural foundation. Systems are designed assuming continuous verification rather than implicit trust.

The most resilient platforms will not be the ones with the best secret-management playbooks. They will be the ones that no longer depend on secrets as a primary security mechanism.

Final Thought

Credentials were a useful abstraction for an earlier era of computing. They helped bridge the gap between static systems and automated access. But they were never meant to scale to the level of dynamism we now take for granted.

Modern cloud security is not about guarding secrets more carefully. It is about designing systems that can verify identity continuously and enforce intent precisely. Once you embrace that shift, credentials stop looking like a necessity, and start looking like a legacy constraint.

Terraform Basics

Saurabh Ahuja — Sun, 14 Dec 2025 20:16:38 +0000

What is Terraform?
Installation
Core Concepts
Basic Examples
State Management
Variables and Outputs
Modules
Common Commands
Best Practices

What is Terraform?

Terraform is an Infrastructure as Code (IaC) tool developed by HashiCorp. It allows you to define and provision infrastructure using a declarative configuration language called HCL (HashiCorp Configuration Language).

Key Benefits (with details and limitations):

Declarative: Describe what you want, not how to get it
- Better than imperative (using python/java/go sdk's). Terraform figures out how to achieve the state, simply declare, I want se bucket with versioning enabled. Complexity of calling the API is hidden.
Multi-cloud: Works with AWS, Azure, GCP, and many other providers
- Terraform's architecture is built on a lightweight core binary that leverages a powerful plugin-based system. Providers—which interface with cloud platforms and services—are downloaded automatically during initialization (terraform init), enabling support for major public clouds and hundreds of other infrastructure providers without requiring a large installation footprint.
Version Control: Infrastructure code can be versioned like application code
- Terraform configuration files serve as the single source of truth for infrastructure. Since all changes are made through code, manual configuration drift is eliminated, and we can track every infrastructure change through version control systems like Git, enabling full audit trails and rollback capabilities.
Idempotent: Running the same configuration multiple times produces the same result
- While idempotency is a key advantage, some cloud providers impose limitations that can affect this behavior. For example, both AWS and Google Cloud Platform (GCP) have mandatory deletion waiting periods for KMS keys. AWS KMS keys enter a scheduled deletion state and cannot be fully removed for 7-30 days (configurable), while GCP Cloud KMS key versions remain in a "scheduled for destruction" state for typically 30 days. This means that attempting to destroy and immediately recreate a KMS key with the same name will fail, as the key still exists in a pending deletion state. Such provider-specific constraints can prevent true idempotency in certain scenarios, requiring careful resource naming strategies or waiting periods between destroy and recreate operations.
State Management: Tracks the current state of your infrastructure
- The state file is critical for Terraform to understand and manage your infrastructure. However, migrating state files during major Terraform version upgrades or backend changes can be complex and may require manual intervention. While Terraform provides migration tools (like terraform init -migrate-state), careful planning and testing are essential to ensure state compatibility and avoid accidental infrastructure destruction during the migration process.

Installation

macOS

brew install terraform

Linux

wget https://releases.hashicorp.com/terraform/1.6.0/terraform_1.6.0_linux_amd64.zip
unzip terraform_1.6.0_linux_amd64.zip
sudo mv terraform /usr/local/bin/

Verify Installation

terraform version

Core Concepts

1. Providers

Providers are plugins that Terraform uses to interact with cloud platforms, SaaS providers, and other APIs.

2. Resources

Resources are the most important element in Terraform. They represent infrastructure objects like virtual machines, networks, databases, etc.

3. Data Sources

Data sources allow you to fetch and use information from existing infrastructure or external systems. Unlike resources, data sources are read-only and don't create, modify, or destroy anything. They're useful for referencing existing resources, getting the latest AMI IDs, querying VPC information, or retrieving data from external APIs.

4. Variables

Variables allow you to parameterize your configurations.

5. Outputs

Outputs expose information about your infrastructure after it's created.

6. State

Terraform stores the state of your infrastructure in a state file, which tracks what resources exist and their current configuration.

Basic Examples

Prerequisites

Before running the examples below, ensure you have:

Terraform binary - Install Terraform and specify the version in your configuration
Providers - Declare required providers with version constraints in your Terraform configuration
Cloud credentials - Configure authentication for cloud providers (AWS, GCP, Azure, etc.)

Example 1: Local File Resource (doesn't require credentials)

Create a file called main.tf:

terraform {
  required_version = ">= 1.0"
}

# Create a local file
resource "local_file" "example" {
  filename = "example.txt"
  content  = "Hello, Terraform!"
}

Commands:

terraform init      # Initialize Terraform
terraform plan      # Preview changes
terraform apply     # Apply changes
terraform destroy   # Remove resources

Example 2: AWS S3 Bucket

terraform {
  required_version = ">= 1.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

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

# Create an S3 bucket
resource "aws_s3_bucket" "example" {
  bucket = "my-terraform-example-bucket-2024"

  tags = {
    Name        = "Example Bucket"
    Environment = "Development"
  }
}

# Enable versioning
resource "aws_s3_bucket_versioning" "example" {
  bucket = aws_s3_bucket.example.id

  versioning_configuration {
    status = "Enabled"
  }
}

Setup:

# Configure AWS credentials
aws configure

# Initialize and apply
terraform init
terraform plan
terraform apply

Example 3: Google Cloud Storage (GCS) Bucket

terraform {
  required_version = ">= 1.0"

  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 5.0"
    }
  }
}

provider "google" {
  project = "your-project-id"  # Replace with your GCP project ID
  region  = "us-central1" # specify region
}

# Create a GCS bucket
resource "google_storage_bucket" "example" {
  name          = "my-terraform-example-bucket-2025"  # Must be globally unique
  location      = "US"
  force_destroy = false  # Set to true to allow deletion of non-empty bucket

  # Enable versioning
  versioning {
    enabled = true
  }

  # Lifecycle rules
  lifecycle_rule {
    condition {
      age = 30
    }
    action {
      type = "Delete"
    }
  }

  # Uniform bucket-level access
  uniform_bucket_level_access = true

  # Labels
  labels = {
    environment = "development"
    managed-by  = "terraform"
  }
}

# Set bucket IAM policy (optional)
resource "google_storage_bucket_iam_member" "public_read" {
  bucket = google_storage_bucket.example.name
  role   = "roles/storage.objectViewer"
  member = "allUsers"
}

# Output the bucket URL
output "bucket_url" {
  value       = google_storage_bucket.example.url
  description = "URL of the GCS bucket"
}

output "bucket_name" {
  value       = google_storage_bucket.example.name
  description = "Name of the GCS bucket"
}

Setup:

# Authenticate with Google Cloud
gcloud auth application-default login

# Set your project
gcloud config set project your-project-id

# Initialize and apply
terraform init
terraform plan
terraform apply

State Management

Local State (Default)

By default, Terraform stores state locally in a file called terraform.tfstate.

Remote State (Recommended for Teams)

Store state in a remote backend to enable team collaboration and state locking. Examples for AWS S3 and Google Cloud Storage (GCS):

AWS S3 Backend:

terraform {
  backend "s3" {
    bucket = "my-terraform-state-bucket"
    key    = "terraform.tfstate"
    region = "us-east-1"

    # Enable state locking with DynamoDB
    dynamodb_table = "terraform-state-lock"
    encrypt        = true
  }
}

Google Cloud Storage (GCS) Backend:

terraform {
  backend "gcs" {
    bucket = "my-terraform-state-bucket"
    prefix = "terraform/state"

    # Optional: Enable state locking (requires Cloud Storage bucket with versioning)
    # State locking is automatically enabled with GCS backend
  }
}

State Commands

terraform state list              # List all resources in state
terraform state show <resource>   # Show details of a resource
terraform state mv <old> <new>    # Move a resource in state
terraform state rm <resource>     # Remove a resource from state

Variables and Outputs

Variables Example

Create variables.tf:

variable "region" {
  description = "AWS region"
  type        = string
  default     = "us-east-1"
}

variable "instance_type" {
  description = "EC2 instance type"
  type        = string
  default     = "t2.micro"
}

variable "environment" {
  description = "Environment name"
  type        = string
  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "Environment must be dev, staging, or prod."
  }
}

variable "tags" {
  description = "Common tags for all resources"
  type        = map(string)
  default = {
    Project = "Terraform-101"
    ManagedBy = "Terraform"
  }
}

Create terraform.tfvars:

region        = "us-west-2"
instance_type = "t3.small"
environment   = "dev"

tags = {
  Project     = "Terraform-101"
  ManagedBy   = "Terraform"
  Owner       = "DevOps Team"
}

Update main.tf to use variables:

provider "aws" {
  region = var.region
}

resource "aws_instance" "example" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = var.instance_type

  tags = merge(
    var.tags,
    {
      Name        = "example-instance-${var.environment}"
      Environment = var.environment
    }
  )
}

Outputs Example

Create outputs.tf:

output "instance_id" {
  description = "ID of the EC2 instance"
  value       = aws_instance.example.id
}

output "instance_public_ip" {
  description = "Public IP address of the EC2 instance"
  value       = aws_instance.example.public_ip
}

output "instance_arn" {
  description = "ARN of the EC2 instance"
  value       = aws_instance.example.arn
  sensitive   = false
}

Modules

Modules are reusable Terraform configurations. They help organize and encapsulate infrastructure.

Using a Module

module "vpc" {
  source = "./modules/vpc"

  vpc_cidr = "10.0.0.0/16"
  environment = "production"

  tags = {
    Project = "Terraform-101"
  }
}

# Reference module outputs
resource "aws_instance" "web" {
  subnet_id = module.vpc.public_subnet_id
  # ...
}

Creating a Module

Create modules/vpc/main.tf:

variable "vpc_cidr" {
  description = "CIDR block for VPC"
  type        = string
}

variable "environment" {
  description = "Environment name"
  type        = string
}

variable "tags" {
  description = "Tags to apply to resources"
  type        = map(string)
  default     = {}
}

resource "aws_vpc" "main" {
  cidr_block = var.vpc_cidr
  tags = merge(
    var.tags,
    {
      Name        = "vpc-${var.environment}"
      Environment = var.environment
    }
  )
}

output "vpc_id" {
  value = aws_vpc.main.id
}

output "vpc_cidr" {
  value = aws_vpc.main.cidr_block
}

Using Public Modules

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"

  name = "my-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["us-east-1a", "us-east-1b", "us-east-1c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]

  enable_nat_gateway = true
  enable_vpn_gateway = false

  tags = {
    Terraform   = "true"
    Environment = "dev"
  }
}

Common Commands

Basic Workflow

# Initialize Terraform
terraform init

# Format code
terraform fmt

# Validate configuration
terraform validate

# Plan changes
terraform plan

# Apply changes
terraform apply

# Apply with auto-approve (use with caution)
terraform apply -auto-approve

# Destroy infrastructure
terraform destroy

# Show current state
terraform show

Best Practices

1. File Organization

project/
├── main.tf          # Main resources
├── variables.tf     # Variable declarations
├── outputs.tf      # Output definitions
├── terraform.tfvars # Variable values
├── providers.tf    # Provider configuration
└── modules/        # Reusable modules
    └── vpc/
        ├── main.tf
        ├── variables.tf
        └── outputs.tf

2. Use Version Constraints

terraform {
  required_version = ">= 1.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"  # Allows 5.x but not 6.0
    }
  }
}

3. Use Variables, Not Hardcoded Values

# ❌ Bad
resource "aws_instance" "example" {
  instance_type = "t2.micro"
}

# ✅ Good
resource "aws_instance" "example" {
  instance_type = var.instance_type
}

4. Use Meaningful Resource Names

# ❌ Bad
resource "aws_instance" "a" { }

# ✅ Good
resource "aws_instance" "web_server" { }

5. Tag Your Resources

resource "aws_instance" "example" {
  tags = {
    Name        = "web-server"
    Environment = var.environment
    Project     = "Terraform-101"
    ManagedBy   = "Terraform"
  }
}

6. Use Remote State

Store state in a remote backend (S3, Azure Storage, GCS) for team collaboration.

7. Use Workspaces for Environments

terraform workspace new dev
terraform workspace new staging
terraform workspace new prod

8. Validate and Format Before Committing

terraform fmt -recursive
terraform validate

9. Use Data Sources

# Get the latest AMI
data "aws_ami" "amazon_linux" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-gp2"]
  }
}

resource "aws_instance" "example" {
  ami = data.aws_ami.amazon_linux.id
  # ...
}

10. Use `terraform.tfvars` for Sensitive Data

Never commit terraform.tfvars with secrets. Use environment variables or secret management:

export TF_VAR_db_password="secret-password"

Common Patterns

Conditional Resources

resource "aws_instance" "example" {
  count = var.create_instance ? 1 : 0

  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = var.instance_type
}

For Each Loop

variable "regions" {
  type = map(object({
    cidr = string
  }))
  default = {
    us-east-1 = { cidr = "10.0.0.0/16" }
    us-west-2 = { cidr = "10.1.0.0/16" }
  }
}

resource "aws_vpc" "example" {
  for_each = var.regions

  cidr_block = each.value.cidr

  tags = {
    Name = "vpc-${each.key}"
  }
}

Locals for Computed Values

locals {
  common_tags = {
    Project     = "Terraform-101"
    Environment = var.environment
    ManagedBy   = "Terraform"
  }

  instance_name = "${var.project_name}-${var.environment}-${var.instance_type}"
}

resource "aws_instance" "example" {
  tags = local.common_tags
  # ...
}

Troubleshooting

Common Issues

State Lock Error

   terraform force-unlock <LOCK_ID>

Provider Not Found

   terraform init -upgrade

State Out of Sync

   terraform refresh
   terraform plan

Import Existing Resources

   terraform import aws_s3_bucket.example my-bucket-name

Next Steps

Practice: Start with local resources, then move to cloud providers
Learn Modules: Create reusable modules for common patterns
State Management: Set up remote state backends
CI/CD Integration: Integrate Terraform into your CI/CD pipeline
Advanced Topics: Learn about Terraform Cloud, opa policies, and workspaces

Resources

Happy Terraforming! 🚀

Thinking of Learning Google Cloud? Start Here

Saurabh Ahuja — Sat, 11 Oct 2025 14:27:13 +0000

Welcome to the first article in "Learn Google Cloud" series!
I have been tinkering with Software for over 20 years, and I am writing this to help myself as I juggle between various tools and technologies. I want to get a quick refresher on Google Cloud Platform, written by me. Because I am a developer who loves to do hands on. This series may be helpful for other developers looking to learn Google Cloud Platform(gcp). In this series I will focus on Infrastructure as a Service(IaaS) and will be using Terraform

The GCP Free Tier: Your Playground

One of the best ways to learn is by doing, and Google makes this accessible with its generous free tier:

Free Trial Benefits:

$300 credit for 90 days to explore any GCP service
No automatic charges when trial ends

Always Free Tier (doesn't expire):

Compute Engine: 1 e2-micro instance per month
Cloud Storage: 5GB of Standard Storage
BigQuery: 1TB of queries per month
Cloud Functions: 2 million invocations per month
And many more services with free monthly quotas

This means you can build and run real applications without spending a cent initially.

What You'll Need to Get Started

To follow along with this series, you'll need:

A Google Account: Any Gmail or Google Workspace account works
A Credit Card: Required for free trial signup, but you won't be charged without your permission
Basic Technical Knowledge: Familiarity with the command line, basic networking concepts, and Terraform
Curiosity and Patience: Cloud platforms are vast—take time to experiment and learn

Creating Your First GCP Account

Let's get started:

Navigate to Google Cloud Console: Go to console.cloud.google.com
Sign In: Use your Google account credentials
Activate Free Trial: Click on "Activate" and follow the prompts
- Accept terms of service
- Choose your country
- Add payment information (for verification only)

Create Your First Project: GCP organizes resources into projects
- Give it a meaningful name (e.g., "learn-gcp")
- Note your Project ID (unique identifier)

Explore the Console: Take a moment to familiarize yourself with the navigation menu

Key Concepts to Understand

Before we dive deep in upcoming articles, here are foundational concepts:

Projects: The basic organizing entity in GCP. All resources belong to a project. Projects provide isolation and resource management boundaries.

Resources: Everything you create in GCP—virtual machines, databases, storage buckets—is a resource.

Services: GCP offers 100+ services across compute, storage, databases, networking, AI/ML, and more.

APIs: Every GCP service is accessed via APIs. The console is just a UI wrapper around these APIs.

Regions and Zones: GCP infrastructure is distributed globally across regions (geographical locations) and zones (isolated locations within regions).

What's Coming Next

In the next articles, we'll dive into Google Cloud fundamentals, services offered, and provision resources using teraform:

GCP's well-architected framework
GCP Services Offered
Install gcloud command line.
Terraform basics.

By the end of this series, you'll have hands-on experience with the most important GCP services and be ready to architect, build, and deploy production applications on Google Cloud.

First Assignment

Before the next article, I encourage the reader to:

Create your GCP account and activate the free trial
Explore the console interface—click around and see what services are available
Create a simple project and note your Project ID
Enable the Cloud Shell (icon in the top-right corner) and run gcloud config list to see your configuration.

The cloud journey can feel overwhelming at first, but remember—every expert was once a beginner. Take it one step at a time, experiment fearlessly (that's what the free tier is for!), and don't hesitate to explore beyond what's covered in this series.

References

Official Documentation: cloud.google.com/docs

Have questions or topics you'd like covered? Leave a comment below!