Two talks were on the agenda:

1. What is Enterprise Architecture and Why Should Developers Care? — by Ajmal Saifudeen
2. A 12-Factor Roadmap for Modern PHP Infrastructure — by Ish Sookun (myself)

Before the talks, Nirvan Pagooah, Engineering Manager at Klanik, welcomed the group and gave a brief presentation about the company, its activities, and the current open positions.

Enterprise Architecture: Not Just for the Big Players

Ajmal Saifudeen from Enterprise Architects Ltd kicked things off with a presentation that tackled a subject most developers in Mauritius rarely encounter head-on: Enterprise Architecture (EA).

Ajmal opened by framing the Mauritius context. Few organisations on the island have a formal EA practice — or even know what EA is. Most developers never interact with it directly. Yet, as he pointed out, Enterprise Architecture shapes the very environment in which all development happens. Whether you're aware of it or not, EA decisions (or the absence of them) affect every line of code you ship.

Before diving into the enterprise side, Ajmal grounded the audience in what "architecture" means in a general sense. He broke it down into four pillars:

• a blueprint that guides constructors on how and when to build;
• a context — a boundary defined by locality;
• a set of guidelines to follow;
• a set of standards to adhere to.

Simple, but a useful mental model for the discussion that followed.

One of the striking slides was the iceberg analogy for why good architecture matters. Above the waterline sit the external touchpoints — websites, mobile apps, conversational interfaces — the parts users see. Below the surface lurk the problems that plague organisations without solid architecture: lack of agility, complex and disparate systems, organisational silos, poorly managed data, weak resource planning, and ballooning operational costs. The message was clear — what the customer sees is only the tip; the bulk of the challenge lies underneath.

What EA Is (and What It Is Not)

Ajmal offered a concise definition: Enterprise Architecture is the practice of designing how a business operates and how technology supports it, so that technical solutions are purposeful, scalable, and aligned with business goals.

He was equally clear about common misconceptions. EA is not just documentation. It is not a rigid bureaucracy. And importantly, it is not only for large corporates — a point that resonated with an audience largely composed of developers working across a mix of startup, mid-size, and enterprise environments in Mauritius.

Ajmal walked through the EA mandate using a layered pyramid model, spanning from Technology Architecture at the base through Integration, Application, and Information Architecture up to Business Architecture at the apex. Each layer maps to a landscape view — technology, integration, application, data, and business — and the whole stack is driven from the top (business strategy) while being enabled from the bottom (technology capabilities). It was a clear illustration of how EA bridges the gap between what the business wants and what IT delivers.

Sadly, I missed the closing segment of his presentation as I attended a phone call. 😔

A 12-Factor Roadmap for Modern PHP Infrastructure

After Ajmal's talk, I took the floor with a presentation on applying the twelve-factor app methodology to modern PHP infrastructure — specifically Laravel.

Origins and Staying Power

I opened with the backstory. The 12-Factor methodology was created by Adam Wiggins and the Heroku engineering team, published in November 2011 at 12factor.net. It codified the patterns they observed separating apps that scaled reliably from those that repeatedly failed on their platform. What makes it enduring is that Docker (2013) and Kubernetes (2014) both validated its principles, and today serverless, microservices, and CI/CD pipelines all build on the same foundations. Organisations like Netflix, Spotify, Airbnb, Google Cloud, and AWS publicly endorse and implement 12-Factor patterns across their platforms.

The Twelve Factors in Brief

I walked through all twelve factors in two groups. Factors I through VI cover the foundation: a single codebase tracked in version control with many deploys, explicitly declared dependencies via composer.json, configuration stored in environment variables rather than code, backing services (databases, caches, queues) treated as attached resources, strict separation of build/release/run stages, and stateless share-nothing processes.

Factors VII through XII cover runtime and operations: self-contained port binding (Laravel Octane serving on a port), horizontal scaling via the process model, fast startup and graceful shutdown for disposability, keeping dev/staging/production as similar as possible, treating logs as event streams rather than files, and running admin tasks (migrations, seeders) as one-off processes through Artisan.

Laravel × 12-Factor: A Natural Fit

The core of the talk demonstrated how Laravel's architecture aligns with 12-Factor almost by design. The .env file and env() helper give you Factor III (Config) out of the box. composer.json handles Factor II (Dependencies). The driver-based service abstraction in config/database.php, config/cache.php, and config/filesystems.php is Factor IV (Backing Services) in action — you can swap from MySQL to PostgreSQL, from file cache to Redis, or from local disk to S3, all by changing a single environment variable with zero code changes.

For Factors XI and XII, Laravel's Monolog integration routes logs to stderr in production containers, where the platform (Fluentd, Loki, CloudWatch) handles collection. Artisan provides the CLI for migrations, cache clearing, queue management, and custom one-off commands — in Kubernetes, these run as initContainers or Jobs.

Local Dev Parity with Laravel Herd

A significant portion of the talk focused on Factor X (Dev/Prod Parity) through Laravel Herd. Herd is a native PHP development environment for macOS and Windows that provides zero-configuration setup, automatic .test domains with HTTPS, multiple PHP version support (8.1 through 8.5), and built-in services including MySQL, PostgreSQL, Redis, Mailpit, and MinIO for S3-compatible storage. A herd.yml file declares the site configuration declaratively.

I contrasted the local Herd setup against a production Kubernetes deployment side by side: locally you run file cache, sync queues, and local disk; in production it's Redis cache, Redis queues, and S3 storage — but the application code, routes, and business logic remain identical. Only the .env changes.

Lunch and Open Discussion

Post-lunch, we shifted into an open discussion that brought both topics together. Questions ranged from how EA principles can inform infrastructure decisions to how the twelve-factor approach can serve as a lightweight architectural discipline even in organisations without a formal EA function. The cross-pollination between the two talks made for a richer conversation than either topic would have generated in isolation.

The evening began with a warm welcome from Sareeta Nundloll-Goundan, President of PMI Mauritius, who introduced the speaker and noted that this was actually Nadjma Rawat's second time delivering her talk on grooming and personal branding at PMI Mauritius — a testament to how well it had been received the first time around.

Nadjma wasted no time and opened with a simple game. She called out words like danger, calm, love, nature, and asked us to shout out the first colour that came to mind. The room responded almost in unison most of the time. It was a striking demonstration of how deeply colour is wired into our psychology before any rational thought kicks in.

That exercise set the stage for her core argument: colour perception changes body chemistry. The human brain processes visual data in milliseconds and makes snap judgements — about safety, competence, and trustworthiness — before a single word is spoken. This is what she called Visual Intelligence.

From Project Dashboards to People

If you work in project management, you already know RAG status. Red, Amber, Green — the traffic light system used to communicate the health of a project's scope, schedule, and budget at a glance.

Nadjma's insight was to flip this framework inward. Your professional image is your personal RAG report. Stakeholders, clients, and colleagues are unconsciously reading you the moment you walk into a room or join a video call.

The slide she presented on Red Alerts made this concrete:

And here's what made it land: she backed each category with a concrete impact figure.

The grooming point particularly stuck with me: "Poor grooming suggests you are a victim of the project's pressure rather than its manager." That framing is hard to argue with. 🤔

Clothing: Dressing with Intention

One of the most practical segments of Nadjma's session was on clothing — not fashion, but intentional dressing. The key principle she opened with: focus on how the clothes feel and move, not just how they look on the hanger.

The slide she showed contrasted two silhouettes side by side — one labelled Unintentional, the other Intentional. The difference wasn't expensive clothing. It was controlled fabric contrast, a cohesive colour family, and a silhouette that balanced the body. The unintentional look had mismatched textures, random colour temperature, and an uneven silhouette. Small details, massive difference in perception.

Fabric: The Breathability Test

Nadjma was direct about fabric choices: stick to cotton, linen-blends, and "Cool Wool." Avoid 100% polyester — it traps heat, creates sweat patches, and often has a cheap shine that reads as low quality under lighting, whether in a boardroom or on a video call.

Her practical tip before buying: scrunch a bit of the fabric in your hand for 5 seconds. If it bounces back, it's a high-twist fabric that resists wrinkles. If it stays creased, it will look creased by 10 a.m. on your most important day. 🤯

The Fit Rules

Fit matters more than brand. Nadjma shared two simple checks:

• The Shoulder Anchor — the seam of your shirt or jacket should sit exactly where your arm meets your shoulder. If it droops or pulls inward, the fit is wrong regardless of the size on the label.
• The One-Finger Rule — you should be able to slide exactly one finger comfortably between your shirt collar and your neck. Too tight reads as uncomfortable and anxious. Too loose looks careless.

From Red Alert to Green Zone ✅

The takeaway isn't that you need an expensive wardrobe or a perfect appearance. It's about intentionality. A Green status isn't flawless — it's in control. Clean clothes that fit, polished shoes, a tidy video background, structured emails with a clear subject line. These are all signals that say: I have my house in order, and I can manage yours too.

For PMs especially, this matters because you are often the first point of contact for senior stakeholders and investors. Your image is the dashboard they're reading long before your project plan is ever opened.

A Different Kind of (Personal) Project to Manage

Lesson learned from Nadjma's session is that managing your professional image isn't vanity — it's stakeholder communication. Every detail you present visually is data that people are processing, consciously or not.

The next time you're preparing for a big presentation or a stakeholder meeting, run a quick RAG check on yourself. 🧐 Not just your slides — your clothes, your background, your posture, your email subject line. It takes five minutes and could change how the entire room receives what you have to say. Make your own checklist and go through it.

openSUSE Leap 16.0 is now available as a public image on Google Cloud Platform. Both x86_64 and Arm64 images were built on 16 February 2026 and are ready for use with Compute Engine instances.

Launching an instance with openSUSE Leap 16.0

Getting started with Leap 16.0 on GCP is straightforward. From the Google Cloud Console, navigate to Compute Engine > VM instances and click Create Instance.

In the instance configuration page, scroll down to the OS and storage section and click Change to open the boot disk configuration panel.

Under the Public images tab, select openSUSE from the Operating system dropdown. You will then see openSUSE Leap listed under the Version dropdown — select the openSUSE Leap 16.0 entry. Choose your preferred boot disk type and size, then click Select to confirm.

From there, configure the rest of your instance settings — machine type, networking, firewall rules — as you normally would, and click Create to launch your new Leap 16.0 VM.

A note on Google Cloud Observability

During instance creation, you will notice the Observability - Ops Agent section near the bottom of the configuration page. For supported operating systems, this provides a convenient Install Ops Agent for Monitoring and Logging checkbox that automatically installs the agent when the VM boots. However, with openSUSE Leap 16.0 selected as the boot disk image, this checkbox is greyed out and displays the message: "Not available for the selected image." This is because the automated installation method does not yet support Leap 16.0.

You might think the next step would be to install the Ops Agent manually via the command line. Google's installation documentation provides a script for exactly this:

curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --also-install

Unfortunately, this does not work on Leap 16.0 either — and the reason is buried in how the script identifies your operating system.

Why does the script fail?

The script reads /etc/os-release to determine the OS family and version. For any SUSE-based distribution, including openSUSE Leap, it routes to a handle_suse function via a case statement in main():

sles|opensuse-leap) handle_suse ;;

Inside handle_suse, the add_repo() function extracts the major version number and constructs a SLES-based repository codename:

local SUSE_VERSION=${VERSION_ID%%.*}
local CODENAME="${REPO_CODENAME:-"sles${SUSE_VERSION}"}"

On openSUSE Leap 16.0, VERSION_ID is 16.0, so SUSE_VERSION resolves to 16 and the codename becomes sles16. The script then attempts to add a repository at:

https://packages.cloud.google.com/yum/repos/google-cloud-ops-agent-sles16-$basearch-all

The problem is that this repository simply does not exist. Google currently publishes Ops Agent packages for sles12 and sles15, but there is no sles16 repository — SLES 16 itself has not been released yet. The script makes no distinction between SLES and openSUSE Leap; it treats both as the same platform and derives the repo path purely from the major version number. The result is a refresh_failed error telling you to check your network connectivity and verify that you are running a supported distribution.

This leaves openSUSE Leap users on GCP in a bit of a gap. While the Ops Agent officially supports Leap 15.6, that image is no longer available on GCP — only Leap 16.0 is offered as a public image. So the supported version cannot be deployed, and the deployable version is not supported. Until Google publishes a compatible repository for Leap 16.0, there is no straightforward path to running the Ops Agent on an openSUSE instance on GCP. Keep an eye on the Ops Agent supported platforms list for updates.

Installing the Leap 15.6 version of the agent isn't a viable workaround due to missing libraries.

Problem: 1: nothing provides 'libcrypto.so.1.1()(64bit)' needed by the to be installed google-cloud-ops-agent-2.63.0-1.sles15.x86_64

As always, the openSUSE community welcomes feedback and bug reports — if you run into issues with the GCP images that are specific to the openSUSE project, report them through the openSUSE Bugzilla.

Two seats on the openSUSE Board are up for grabs as Simon Lees and Shawn W Dunn complete their mandate. This is a great opportunity for community members who want to help shape the direction of the openSUSE Project.

Key dates

• 27 February – Deadline for candidates to declare their intention
• 28 February – Candidate slate published
• 1 March – Voting opens
• 9 March – Results announced (ballots remain open for one week)

Who can participate?

Only active openSUSE members are eligible to vote. If you're a contributor but not yet a member, you can apply for membership at any time. Members who join after the candidate slate is published on 28 February can still vote, but will not be able to run as a candidate.

If your membership is approved after voting has begun, reach out to the election officials to inform them. Membership approval and voting in the election is not an automatic process. The election officials will use an up to data membership database for the election process on the 1 March when opening the ballots. Thus, membership approvals after that date have to be informed to the officials.

Details on how to become a member are available on the wiki: openSUSE:Members

Get involved

If you're interested in running, reach out to the Election Committee via their mailing list before the 27th of February. The announcement was made on the openSUSE Project mailing list and social media, and the election wiki page has been updated with full details.

The openSUSE Board plays a vital role in guiding the project. Whether you choose to run or simply cast your vote, your participation matters.

When migrating workloads to the cloud, one of the most overlooked challenges is IP address management. Organizations that have built their reputation, whitelists, and infrastructure around specific IP addresses often face a difficult choice: abandon those trusted addresses or maintain expensive on-premises equipment just to keep using them. This challenge is particularly relevant in Mauritius, where Internet leased circuit offerings remain "unfortunately" expensive, making it impractical for small networks to manage their own IP number resources on-premises. Google Cloud's Bring Your Own IP (BYOIP) feature solves this problem, and for organizations in Africa and the Indian Ocean region holding AFRINIC allocations, it opens up exciting possibilities.

This article is based on my experience managing a Public IP Address Prefix allocated by AFRINIC to the company I work for. I'll share the practical insights gained through this process, from understanding the Regional Internet Registry ecosystem to the actual implementation steps that made our IPv4 migration to Google Cloud seamless.

Understanding Regional Internet Registries and AFRINIC

Before diving into the technical bits, it's worth understanding where your IP addresses come from. I find that many developers and even sysadmins don't fully grasp the infrastructure that makes global Internet addressing possible.

The Internet's addressing system is coordinated through a hierarchical structure. At the top sits the Internet Assigned Numbers Authority (IANA), which allocates large blocks of IP addresses to five Regional Internet Registries (RIRs). These RIRs are nonprofit organizations that manage the distribution of Internet number resources within their geographic regions:

• AFRINIC (African Network Information Centre) — Africa and the Indian Ocean
• APNIC (Asia-Pacific Network Information Centre) — East, South, and Southeast Asia, plus Oceania
• ARIN (American Registry for Internet Numbers) — North America, parts of the Caribbean, and Antarctica
• LACNIC (Latin America and Caribbean Network Information Centre) — South and Central America
• RIPE NCC (Réseaux IP Européens Network Coordination Centre) — Europe, the Middle East, and Central Asia

AFRINIC is headquartered in Ébène, Mauritius — yes, right here on our island! It was established in 2004 and received ICANN's final recognition in April 2005, making it the youngest of the five RIRs. As a not-for-profit organization, AFRINIC serves approximately 2,400 members across 56 countries, including Internet service providers, Internet exchange points, governments, academic institutions, and businesses that operate networks.

For a company based in Mauritius holding a /24 Public Advertised Prefix from AFRINIC, this means you have 256 IPv4 addresses that are officially registered and recognized globally as belonging to your organization.

Why Bring Your Own IP (BYOIP) Matters to us (in Africa, particularly Mauritius)?

Google Cloud announced BYOIP in October 2019, becoming the first cloud provider to make this feature globally available across all its regions. However, here's the catch for us in Africa — while BYOIP was available globally since 2019, Google Cloud had no region on the African continent until January 2024, when the africa-south1 region (Johannesburg, South Africa) became operational. This was a significant milestone as it marked Google Cloud's first presence in Africa.

For organizations in Mauritius and across the AFRINIC region, this meant that for nearly five years, using BYOIP required routing traffic through distant regions like europe-west1 or me-west1 (Tel Aviv). Not ideal for latency-sensitive applications. The Johannesburg region changes everything — we now have a Google Cloud region connected to Mauritius via three submarine cables.

The BYOIP Architecture on Google Cloud

Google Cloud's BYOIP implementation revolves around two key concepts: the Public Advertised Prefix (PAP) and Public Delegated Prefixes (PDPs).

A Public Advertised Prefix is your IP address block as registered with Google Cloud. This is where ownership verification happens through Route Origin Authorization (ROA) and reverse DNS validation. After verification is complete, Google configures the announcement of this prefix to the Internet, but the prefix is not advertised until it is provisioned. The provisioning process takes approximately four weeks.

A Public Delegated Prefix is a subdivision of your PAP that you configure for use in a specific scope—either a particular region or globally. You can break up your PAP into multiple PDPs to distribute addresses across different regions or use cases. These PDPs can be further divided into sub-prefixes, giving you granular control over how your IP addresses are used.

Setting Up BYOIP

Let me walk you through how I configured our company's AFRINIC-allocated /24 prefix on Google Cloud. The process requires coordination between your Regional Internet Registry (AFRINIC in our case) and Google Cloud.

Prerequisites and ROA Configuration

Before touching the Google Cloud Console, you need to create a Route Origin Authorization (ROA) with AFRINIC. The ROA is a cryptographically signed statement that authorizes Google's Autonomous System Number (ASN) to advertise your IP prefix. Google uses ASN 396982 for BYOIP announcements.

The ROA must include your prefix range, Google's ASN, and an appropriate expiration date. This authorization is registered with the Resource Public Key Infrastructure (RPKI), which allows BGP routers worldwide to verify the legitimacy of route announcements.

I won't go into the details of creating the ROA on AFRINIC's portal here as it is purely textbook instruction. If you're an AFRINIC member, you should be familiar with their MyAFRINIC portal where the RPKI management is done.

Creating the Public Advertised Prefix

With the ROA in place, navigate to the VPC network section in Google Cloud Console. The process begins by creating your Public Advertised Prefix.

Click on "Add PAP" to start creating your Public Advertised Prefix. The first step requires you to enter details for the prefix you want to bring to Google Cloud. Notice the reminder about Route Origin Authorisation Verification — this is why we set up the ROA with AFRINIC beforehand.

You'll need to provide a name for your PAP, select the IP version (IPv4 or IPv6), enter your prefix in CIDR notation, and choose the scope (Regional or Global). The form even shows an example format: 203.0.113.0/24.

After entering your prefix details, Google Cloud will ask you to confirm ownership. Pay attention to the warning here — this information cannot be edited later. Double-check that the net range and CIDR are correct before proceeding.

The final step is validation. Google Cloud verifies your ownership through two methods: DNS validation and Route origin attestation. For DNS validation, you'll need to create a PTR record using the IP address and name provided. The ROA validation checks against the RPKI to confirm that you've authorized Google's ASN to announce your prefix.

Once you've created the PTR record and your ROA is properly configured with AFRINIC, click the checkbox to confirm and hit Validate. When both validations show "Completed", you're good to go!

After validation completes, you'll see your PAP listed with "Prefix configuration in progress" status. This is where patience comes in.

The full provisioning process takes about four weeks. This isn't Google being slow— it's the time needed for route propagation across global BGP infrastructure to ensure stable, reliable routing.

Once provisioning completes, the status changes to "Ready to announce". This is the moment you've been waiting for!

Click on the three-dot menu under Actions and select "Announce" to start advertising your prefix from Google's network.

After announcing, your prefix will be advertised to the Internet from Google Cloud's infrastructure. You can now create Public Delegated Prefixes and start using your BYOIP addresses.

Creating Public Delegated Prefixes

While waiting for your PAP to provision, you can plan how to divide your address space. For a /24 prefix, you might allocate addresses for:

• A /26 for your primary regional workloads
• A /27 for global load balancers
• A /28 for development and testing
• Reserve the remaining space for future use

Each Public Delegated Prefix needs a scope assignment. Regional scope is required if you want to use addresses with Compute Engine VMs or regional load balancers. Global scope is needed for global Application Load Balancers but requires your project to be on an allowlist.

Oh... and about region selection. My usual trick for obtaining the best latency to a region is to understand how our submarine fiber cables connect us to the rest of the world. With the africa-south1 region now available in Johannesburg, this is the obvious choice for organizations in Mauritius and across the AFRINIC region. The region is connected to Europe via the Equiano subsea cable and to Mauritius via the SAFE, METISS and T3 subsea cables.

Delegating Sub-Prefixes to Projects

Once your PDPs are provisioned, you can delegate sub-prefixes to specific projects within your organization. This is where BYOIP shines for enterprise environments—you can maintain centralized control over your IP address space while allowing individual teams to use addresses in their projects.

From the PDP details page, you can see all the information about your Public Delegated Prefix — the status (hopefully "Announced to Internet" ✅), the prefix details, scope, and any existing sub-delegates. Notice in the screenshot below that the scope is set to africa-south1.

To create a sub-prefix, click on "Create sub-prefix". You'll need to provide a name, select the prefix length (how many addresses you want to delegate), choose the specific IP range, and assign it to a project.

In this example, I'm creating a /26 sub-prefix (64 addresses) and assigning it to the "LSL IT" project. You can create multiple sub-prefixes of different sizes depending on your needs.

Once the sub-prefix is delegated to a project, you can create addresses from that pool. The "Create addresses" dialog lets you permanently delegate specific addresses to the project.

Here I'm creating 2 addresses from a /31 block. Once created, these addresses become available for use with Compute Engine instances, load balancers, and other Google Cloud resources within that project.

Using BYOIP Addresses with Compute Engine

With your addresses provisioned and delegated, using them with Compute Engine instances is straightforward. When creating a VM instance, navigate to the Networking section and expand the network interface settings. Under "External IPv4 address", you'll see your BYOIP addresses listed alongside the usual options.

Notice in the screenshot that the BYOIP addresses (the 102.x.x.x addresses) appear in the dropdown with "Premium tier" — these are your AFRINIC-allocated addresses now usable directly on Google Cloud! Also notice the machine is being created in africa-south1-a and running openSUSE Leap 16.0. 😉

The address behaves exactly like any Google-provided address — you can assign it to VM instances, use it with NAT gateways (with some limitations), and include it in firewall rules. The key differences are that your BYOIP addresses are available only to your organization, and there are no charges for idle or in-use addresses.

Introduction

In today's multi-cloud landscape, managing authentication credentials across different cloud providers has become a significant security challenge. Traditional approaches using long-lived service account keys pose serious risks: they can be leaked, stolen, or compromised, and they're difficult to rotate and audit effectively.

Google Cloud Workload Identity Federation solves this problem by enabling keyless authentication. It allows workloads running outside Google Cloud—such as AWS EC2 instances, Azure VMs, GitHub Actions, or on-premises systems—to securely access Google Cloud resources without managing service account keys.

In this comprehensive guide, we'll walk through a real-world scenario and implement Workload Identity Federation step-by-step.

The Scenario: Multi-Cloud CI/CD Pipeline

Company: TechFlow Inc., a fintech startup
Challenge: Their application runs on Google Cloud (Cloud Run, Cloud SQL PostgreSQL), but their CI/CD pipelines run on GitHub Actions. They need to deploy applications and run database migrations on Cloud SQL from GitHub workflows without storing service account keys in GitHub secrets.

Current Problem:

• Service account keys stored in GitHub Secrets
• Keys need manual rotation every 90 days
• Risk of key exposure if repository is compromised
• Compliance concerns about credential management
• Database credentials management complexity

Goal: Implement Workload Identity Federation to enable GitHub Actions to authenticate to Google Cloud using OIDC tokens, eliminating the need for service account keys entirely.

Architecture Overview

Here's how Workload Identity Federation works:

1. GitHub Actions generates an OIDC token containing claims about the workflow (repository, branch, actor)
2. Workload Identity Pool in Google Cloud validates the token
3. Workload Identity Provider maps the external identity to a Google Cloud service account
4. GitHub Actions receives short-lived Google Cloud credentials
5. Workflow uses credentials to access Google Cloud resources

┌─────────────────┐         ┌──────────────────────────┐
│  GitHub Actions │         │  Google Cloud            │
│                 │         │                          │
│  1. Get OIDC    │────────▶│  2. Workload Identity    │
│     Token       │         │     Pool validates token │
│                 │         │                          │
│  4. Receive     │◀────────│  3. Map to Service       │
│     GCP Token   │         │     Account              │
│                 │         │                          │
│  5. Access GCP  │────────▶│  6. Cloud Run, Cloud SQL │
│     Resources   │         │     (authorized access)  │
└─────────────────┘         └──────────────────────────┘

Prerequisites

Before we begin, ensure you have:

1. A Google Cloud project with billing enabled
2. gcloud CLI installed and configured
3. Appropriate IAM permissions:
   • roles/iam.workloadIdentityPoolAdmin
   • roles/iam.serviceAccountAdmin
   • roles/resourcemanager.projectIamAdmin
4. A GitHub repository where you'll run workflows

Enable Required APIs

First, enable the necessary Google Cloud APIs:

# Set your project ID
export PROJECT_ID="your-project-id"
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format="value(projectNumber)")

# Enable required APIs
gcloud services enable iamcredentials.googleapis.com \
    cloudresourcemanager.googleapis.com \
    sts.googleapis.com \
    --project=$PROJECT_ID

Create a Service Account

Create a service account that will be impersonated by GitHub Actions:

# Create service account
gcloud iam service-accounts create github-actions-sa \
    --display-name="GitHub Actions Service Account" \
    --description="Service account for GitHub Actions workflows" \
    --project=$PROJECT_ID

# Store the service account email
export SA_EMAIL="github-actions-sa@${PROJECT_ID}.iam.gserviceaccount.com"

Grant Necessary Permissions to Service Account

Grant the service account permissions to perform required operations. For our scenario, we need Cloud Run deployment and Cloud SQL access:

# Cloud Run Admin (to deploy services)
gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:${SA_EMAIL}" \
    --role="roles/run.admin"

# Service Account User (to deploy as a service account)
gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:${SA_EMAIL}" \
    --role="roles/iam.serviceAccountUser"

# Cloud SQL Client (to connect to Cloud SQL instances)
gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:${SA_EMAIL}" \
    --role="roles/cloudsql.client"

# Cloud SQL Admin (to manage instances and run migrations)
gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:${SA_EMAIL}" \
    --role="roles/cloudsql.admin"

# Storage Admin (for artifact storage)
gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:${SA_EMAIL}" \
    --role="roles/storage.admin"

# Secret Manager Secret Accessor (to access database credentials)
gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:${SA_EMAIL}" \
    --role="roles/secretmanager.secretAccessor"

Create Workload Identity Pool

The Workload Identity Pool is a container for managing external identities:

# Create the workload identity pool
gcloud iam workload-identity-pools create "github-pool" \
    --location="global" \
    --display-name="GitHub Actions Pool" \
    --description="Identity pool for GitHub Actions workflows" \
    --project=$PROJECT_ID

# Verify creation
gcloud iam workload-identity-pools describe "github-pool" \
    --location="global" \
    --project=$PROJECT_ID

Create Workload Identity Provider

The provider configures how external tokens are validated and mapped:

# Create the OIDC provider for GitHub Actions
gcloud iam workload-identity-pools providers create-oidc "github-provider" \
    --location="global" \
    --workload-identity-pool="github-pool" \
    --display-name="GitHub Actions Provider" \
    --attribute-mapping="google.subject=assertion.sub,attribute.actor=assertion.actor,attribute.repository=assertion.repository,attribute.repository_owner=assertion.repository_owner" \
    --attribute-condition="assertion.repository_owner=='your-github-org'" \
    --issuer-uri="https://token.actions.githubusercontent.com" \
    --project=$PROJECT_ID

Understanding Attribute Mapping

The --attribute-mapping parameter is crucial. It maps claims from the GitHub OIDC token to Google Cloud attributes:

• google.subject=assertion.sub: Maps the subject claim (unique identifier for the workflow)
• attribute.actor=assertion.actor: Maps the GitHub user who triggered the workflow
• attribute.repository=assertion.repository: Maps the repository name
• attribute.repository_owner=assertion.repository_owner: Maps the repository owner

Understanding Attribute Conditions

The --attribute-condition parameter adds security by restricting which external identities can authenticate:

# Only allow specific organization
assertion.repository_owner=='techflow-inc'

# Only allow specific repository
assertion.repository=='techflow-inc/main-app'

# Allow multiple repositories
assertion.repository in ['techflow-inc/app1', 'techflow-inc/app2']

# Combine conditions
assertion.repository_owner=='techflow-inc' && assertion.repository.startsWith('techflow-inc/prod-')

Important: Replace 'your-github-org' with your actual GitHub organization or username.

Grant Service Account Impersonation Permission

Allow the Workload Identity Pool to impersonate your service account. This is where you define precisely which external identities can impersonate the service account:

# For a specific repository
gcloud iam service-accounts add-iam-policy-binding "${SA_EMAIL}" \
    --role="roles/iam.workloadIdentityUser" \
    --member="principalSet://iam.googleapis.com/projects/${PROJECT_NUMBER}/locations/global/workloadIdentityPools/github-pool/attribute.repository/your-github-username/your-repo-name" \
    --project=$PROJECT_ID

Advanced IAM Binding Examples

Option 1: Allow any repository in your organization

gcloud iam service-accounts add-iam-policy-binding "${SA_EMAIL}" \
    --role="roles/iam.workloadIdentityUser" \
    --member="principalSet://iam.googleapis.com/projects/${PROJECT_NUMBER}/locations/global/workloadIdentityPools/github-pool/attribute.repository_owner/your-github-org" \
    --project=$PROJECT_ID

Option 2: Allow multiple specific repositories

# First repository
gcloud iam service-accounts add-iam-policy-binding "${SA_EMAIL}" \
    --role="roles/iam.workloadIdentityUser" \
    --member="principalSet://iam.googleapis.com/projects/${PROJECT_NUMBER}/locations/global/workloadIdentityPools/github-pool/attribute.repository/your-org/repo-1" \
    --project=$PROJECT_ID

# Second repository
gcloud iam service-accounts add-iam-policy-binding "${SA_EMAIL}" \
    --role="roles/iam.workloadIdentityUser" \
    --member="principalSet://iam.googleapis.com/projects/${PROJECT_NUMBER}/locations/global/workloadIdentityPools/github-pool/attribute.repository/your-org/repo-2" \
    --project=$PROJECT_ID

Option 3: Allow specific branch in a repository

# This requires adding branch to attribute mapping first
gcloud iam workload-identity-pools providers update-oidc "github-provider" \
    --location="global" \
    --workload-identity-pool="github-pool" \
    --attribute-mapping="google.subject=assertion.sub,attribute.actor=assertion.actor,attribute.repository=assertion.repository,attribute.repository_owner=assertion.repository_owner,attribute.ref=assertion.ref" \
    --project=$PROJECT_ID

# Then bind for specific branch
gcloud iam service-accounts add-iam-policy-binding "${SA_EMAIL}" \
    --role="roles/iam.workloadIdentityUser" \
    --member="principalSet://iam.googleapis.com/projects/${PROJECT_NUMBER}/locations/global/workloadIdentityPools/github-pool/attribute.ref/refs/heads/main" \
    --project=$PROJECT_ID

Get the Workload Identity Provider Resource Name

You'll need this for your GitHub Actions workflow:

gcloud iam workload-identity-pools providers describe "github-provider" \
    --location="global" \
    --workload-identity-pool="github-pool" \
    --project=$PROJECT_ID \
    --format="value(name)"

The output will look like:

projects/123456789/locations/global/workloadIdentityPools/github-pool/providers/github-provider

Save this value—you'll use it in your GitHub workflow.

Set Up Cloud SQL Instance and Secrets

Before configuring the workflow, set up your Cloud SQL instance and store credentials securely:

Create Cloud SQL Instance

# Create a PostgreSQL instance
gcloud sql instances create production-db \
    --database-version=POSTGRES_15 \
    --tier=db-custom-2-7680 \
    --region=us-central1 \
    --network=projects/$PROJECT_ID/global/networks/default \
    --no-assign-ip \
    --database-flags=cloudsql.iam_authentication=on \
    --project=$PROJECT_ID

# Create a database
gcloud sql databases create production \
    --instance=production-db \
    --project=$PROJECT_ID

# Create a PostgreSQL user
gcloud sql users create dbuser \
    --instance=production-db \
    --password=STRONG_PASSWORD_HERE \
    --project=$PROJECT_ID

Store Database Password in Secret Manager

# Enable Secret Manager API
gcloud services enable secretmanager.googleapis.com --project=$PROJECT_ID

# Create secret for database password
echo -n "STRONG_PASSWORD_HERE" | gcloud secrets create db-password \
    --data-file=- \
    --replication-policy="automatic" \
    --project=$PROJECT_ID

# Grant service account access to the secret
gcloud secrets add-iam-policy-binding db-password \
    --member="serviceAccount:${SA_EMAIL}" \
    --role="roles/secretmanager.secretAccessor" \
    --project=$PROJECT_ID

Alternative: Use IAM Database Authentication (Recommended)

For enhanced security, use IAM authentication instead of passwords:

# Create an IAM database user
gcloud sql users create github-actions-sa@$PROJECT_ID.iam \
    --instance=production-db \
    --type=CLOUD_IAM_SERVICE_ACCOUNT \
    --project=$PROJECT_ID

# Grant the service account Cloud SQL Client role
gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:${SA_EMAIL}" \
    --role="roles/cloudsql.client"

Then connect using IAM authentication in your workflow:

# Get an IAM token for database authentication
gcloud sql generate-login-token

# Or use Cloud SQL Proxy which handles this automatically
./cloud_sql_proxy -instances=$INSTANCE_CONNECTION_NAME=tcp:5432 \
    --auto-iam-authn

Configure Cloud SQL for Private IP (Best Practice)

# Enable Private Service Access
gcloud compute addresses create google-managed-services-default \
    --global \
    --purpose=VPC_PEERING \
    --prefix-length=16 \
    --network=default \
    --project=$PROJECT_ID

# Create private connection
gcloud services vpc-peerings connect \
    --service=servicenetworking.googleapis.com \
    --ranges=google-managed-services-default \
    --network=default \
    --project=$PROJECT_ID

# Create instance with private IP only
gcloud sql instances create production-db-private \
    --database-version=POSTGRES_15 \
    --tier=db-custom-2-7680 \
    --region=us-central1 \
    --network=projects/$PROJECT_ID/global/networks/default \
    --no-assign-ip \
    --database-flags=cloudsql.iam_authentication=on \
    --project=$PROJECT_ID

Configure GitHub Actions Workflow

Now, create a GitHub Actions workflow that uses Workload Identity Federation:

name: Deploy to Cloud Run and Run Migrations

on:
  push:
    branches:
      - main

# Required for OIDC token generation
permissions:
  contents: read
  id-token: write

jobs:
  deploy:
    runs-on: ubuntu-latest
    
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      # Authenticate to Google Cloud using Workload Identity Federation
      - id: 'auth'
        name: 'Authenticate to Google Cloud'
        uses: 'google-github-actions/auth@v2'
        with:
          workload_identity_provider: 'projects/123456789/locations/global/workloadIdentityPools/github-pool/providers/github-provider'
          service_account: 'github-actions-sa@your-project-id.iam.gserviceaccount.com'
          token_format: 'access_token'

      # Setup Cloud SDK
      - name: 'Set up Cloud SDK'
        uses: 'google-github-actions/setup-gcloud@v2'

      # Install Cloud SQL Proxy
      - name: 'Install Cloud SQL Proxy'
        run: |
          wget https://dl.google.com/cloudsql/cloud_sql_proxy.linux.amd64 -O cloud_sql_proxy
          chmod +x cloud_sql_proxy

      # Build and push Docker image
      - name: 'Build and Push to Artifact Registry'
        run: |
          gcloud auth configure-docker us-central1-docker.pkg.dev
          docker build -t us-central1-docker.pkg.dev/${{ secrets.GCP_PROJECT_ID }}/apps/myapp:${{ github.sha }} .
          docker push us-central1-docker.pkg.dev/${{ secrets.GCP_PROJECT_ID }}/apps/myapp:${{ github.sha }}

      # Run database migrations using Cloud SQL Proxy
      - name: 'Run Database Migrations'
        env:
          INSTANCE_CONNECTION_NAME: ${{ secrets.GCP_PROJECT_ID }}:us-central1:production-db
        run: |
          # Start Cloud SQL Proxy in background
          ./cloud_sql_proxy -instances=$INSTANCE_CONNECTION_NAME=tcp:5432 &
          PROXY_PID=$!
          
          # Wait for proxy to be ready
          sleep 5
          
          # Get database password from Secret Manager
          DB_PASSWORD=$(gcloud secrets versions access latest --secret="db-password")
          
          # Run migrations (example using Flyway)
          export PGPASSWORD=$DB_PASSWORD
          psql -h 127.0.0.1 -p 5432 -U dbuser -d production -f migrations/001_initial_schema.sql
          
          # Or using a migration tool like golang-migrate
          # migrate -path=./migrations -database "postgresql://dbuser:${DB_PASSWORD}@127.0.0.1:5432/production?sslmode=disable" up
          
          # Kill the proxy
          kill $PROXY_PID

      # Deploy to Cloud Run with Cloud SQL connection
      - name: 'Deploy to Cloud Run'
        run: |
          gcloud run deploy myapp \
            --image=us-central1-docker.pkg.dev/${{ secrets.GCP_PROJECT_ID }}/apps/myapp:${{ github.sha }} \
            --region=us-central1 \
            --platform=managed \
            --allow-unauthenticated \
            --add-cloudsql-instances=${{ secrets.GCP_PROJECT_ID }}:us-central1:production-db \
            --set-env-vars="DB_USER=dbuser,DB_NAME=production" \
            --set-secrets="DB_PASSWORD=db-password:latest"

      # Verify deployment and database connectivity
      - name: 'Health Check'
        run: |
          # Get the service URL
          SERVICE_URL=$(gcloud run services describe myapp --region=us-central1 --format='value(status.url)')
          
          # Check health endpoint
          curl -f ${SERVICE_URL}/health || exit 1
          
          # Verify database connection through the app
          curl -f ${SERVICE_URL}/db/ping || exit 1

Key Workflow Elements

1. Permissions Block: The id-token: write permission is crucial—it allows GitHub to generate OIDC tokens.
2. Auth Action: The google-github-actions/auth@v2 action handles the token exchange automatically.
3. No Secrets Required: Notice we don't store any service account keys in GitHub Secrets, only the project ID.
4. Cloud SQL Proxy: The proxy creates a secure tunnel to Cloud SQL, handling authentication via the service account.
5. Secret Manager Integration: Database passwords are stored securely and accessed at runtime.

Advanced Cloud SQL Workflow Patterns

Pattern 1: Using IAM Authentication (Most Secure)

name: Deploy with IAM Database Authentication

on:
  push:
    branches:
      - main

permissions:
  contents: read
  id-token: write

jobs:
  deploy:
    runs-on: ubuntu-latest
    
    steps:
      - uses: actions/checkout@v4

      - id: 'auth'
        uses: 'google-github-actions/auth@v2'
        with:
          workload_identity_provider: 'projects/123456789/locations/global/workloadIdentityPools/github-pool/providers/github-provider'
          service_account: 'github-actions-sa@your-project-id.iam.gserviceaccount.com'

      - uses: 'google-github-actions/setup-gcloud@v2'

      # Use Cloud SQL Auth Proxy with IAM authentication
      - name: 'Run Migrations with IAM Auth'
        run: |
          # Install Cloud SQL Auth Proxy
          curl -o cloud-sql-proxy https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/v2.8.0/cloud-sql-proxy.linux.amd64
          chmod +x cloud-sql-proxy
          
          # Start proxy with automatic IAM authentication
          ./cloud-sql-proxy --auto-iam-authn ${{ secrets.GCP_PROJECT_ID }}:us-central1:production-db &
          PROXY_PID=$!
          sleep 5
          
          # Connect using IAM - no password needed!
          psql "host=127.0.0.1 port=5432 sslmode=disable user=github-actions-sa@${{ secrets.GCP_PROJECT_ID }}.iam dbname=production" \
            -c "SELECT version();"
          
          # Run migrations
          psql "host=127.0.0.1 port=5432 sslmode=disable user=github-actions-sa@${{ secrets.GCP_PROJECT_ID }}.iam dbname=production" \
            -f migrations/schema.sql
          
          kill $PROXY_PID

Pattern 2: Using Flyway for Database Migrations

      - name: 'Run Flyway Migrations'
        env:
          INSTANCE_CONNECTION_NAME: ${{ secrets.GCP_PROJECT_ID }}:us-central1:production-db
        run: |
          # Start Cloud SQL Proxy
          ./cloud_sql_proxy -instances=$INSTANCE_CONNECTION_NAME=tcp:5432 &
          PROXY_PID=$!
          sleep 5
          
          # Get database password
          DB_PASSWORD=$(gcloud secrets versions access latest --secret="db-password")
          
          # Install Flyway
          wget -qO- https://repo1.maven.org/maven2/org/flywaydb/flyway-commandline/10.4.1/flyway-commandline-10.4.1-linux-x64.tar.gz | tar xvz
          
          # Configure Flyway
          ./flyway-10.4.1/flyway \
            -url=jdbc:postgresql://127.0.0.1:5432/production \
            -user=dbuser \
            -password=$DB_PASSWORD \
            -locations=filesystem:./sql/migrations \
            migrate
          
          # Verify migration status
          ./flyway-10.4.1/flyway \
            -url=jdbc:postgresql://127.0.0.1:5432/production \
            -user=dbuser \
            -password=$DB_PASSWORD \
            info
          
          kill $PROXY_PID

Pattern 3: Blue-Green Database Migrations with Rollback

      - name: 'Blue-Green Migration with Rollback'
        run: |
          # Start proxy
          ./cloud_sql_proxy -instances=${{ secrets.GCP_PROJECT_ID }}:us-central1:production-db=tcp:5432 &
          PROXY_PID=$!
          sleep 5
          
          DB_PASSWORD=$(gcloud secrets versions access latest --secret="db-password")
          export PGPASSWORD=$DB_PASSWORD
          
          # Create backup before migration
          pg_dump -h 127.0.0.1 -p 5432 -U dbuser production > backup_$(date +%Y%m%d_%H%M%S).sql
          
          # Upload backup to Cloud Storage
          gcloud storage cp backup_*.sql gs://${{ secrets.GCP_PROJECT_ID }}-db-backups/
          
          # Create test database from production
          psql -h 127.0.0.1 -p 5432 -U dbuser -d postgres \
            -c "CREATE DATABASE production_test WITH TEMPLATE production;"
          
          # Test migrations on copy
          if psql -h 127.0.0.1 -p 5432 -U dbuser -d production_test -f migrations/schema.sql; then
            echo "✓ Migration test successful"
            
            # Apply to production
            psql -h 127.0.0.1 -p 5432 -U dbuser -d production -f migrations/schema.sql
            
            # Verify production migration
            if psql -h 127.0.0.1 -p 5432 -U dbuser -d production -c "SELECT COUNT(*) FROM users;" > /dev/null; then
              echo "✓ Production migration successful"
            else
              echo "✗ Production migration failed, restoring backup"
              psql -h 127.0.0.1 -p 5432 -U dbuser -d production < backup_*.sql
              exit 1
            fi
            
            # Cleanup test database
            psql -h 127.0.0.1 -p 5432 -U dbuser -d postgres \
              -c "DROP DATABASE production_test;"
          else
            echo "✗ Migration test failed, aborting"
            exit 1
          fi
          
          kill $PROXY_PID

Pattern 4: Multi-Region Database Deployment

jobs:
  deploy-multi-region:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        region: 
          - name: us-central1
            db: production-db-us
          - name: europe-west1
            db: production-db-eu
          - name: asia-southeast1
            db: production-db-asia
    
    steps:
      - uses: actions/checkout@v4
      
      - id: 'auth'
        uses: 'google-github-actions/auth@v2'
        with:
          workload_identity_provider: 'projects/123456789/locations/global/workloadIdentityPools/github-pool/providers/github-provider'
          service_account: 'github-actions-sa@your-project-id.iam.gserviceaccount.com'
      
      - uses: 'google-github-actions/setup-gcloud@v2'
      
      - name: 'Deploy to ${{ matrix.region.name }}'
        run: |
          # Install Cloud SQL Proxy
          curl -o cloud-sql-proxy https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/v2.8.0/cloud-sql-proxy.linux.amd64
          chmod +x cloud-sql-proxy
          
          # Start proxy for this region
          ./cloud-sql-proxy ${{ secrets.GCP_PROJECT_ID }}:${{ matrix.region.name }}:${{ matrix.region.db }} &
          PROXY_PID=$!
          sleep 5
          
          # Get region-specific password
          DB_PASSWORD=$(gcloud secrets versions access latest --secret="db-password-${{ matrix.region.name }}")
          export PGPASSWORD=$DB_PASSWORD
          
          # Run common migrations
          psql -h 127.0.0.1 -p 5432 -U dbuser -d production \
            -f migrations/common/schema.sql
          
          # Run region-specific configurations
          psql -h 127.0.0.1 -p 5432 -U dbuser -d production \
            -v region=${{ matrix.region.name }} \
            -f migrations/regional/config.sql
          
          kill $PROXY_PID
          
          # Deploy Cloud Run in this region
          gcloud run deploy myapp-${{ matrix.region.name }} \
            --image=us-central1-docker.pkg.dev/${{ secrets.GCP_PROJECT_ID }}/apps/myapp:${{ github.sha }} \
            --region=${{ matrix.region.name }} \
            --add-cloudsql-instances=${{ secrets.GCP_PROJECT_ID }}:${{ matrix.region.name }}:${{ matrix.region.db }} \
            --set-env-vars="REGION=${{ matrix.region.name }},DB_NAME=production"

Advanced Configuration - Multiple Environments

For production deployments, you'll likely need different service accounts for different environments:

# Create production service account
gcloud iam service-accounts create github-actions-prod-sa \
    --display-name="GitHub Actions Production SA" \
    --project=$PROJECT_ID

export PROD_SA_EMAIL="github-actions-prod-sa@${PROJECT_ID}.iam.gserviceaccount.com"

# Bind only to main branch
gcloud iam service-accounts add-iam-policy-binding "${PROD_SA_EMAIL}" \
    --role="roles/iam.workloadIdentityUser" \
    --member="principalSet://iam.googleapis.com/projects/${PROJECT_NUMBER}/locations/global/workloadIdentityPools/github-pool/attribute.ref/refs/heads/main" \
    --project=$PROJECT_ID

# Create staging service account
gcloud iam service-accounts create github-actions-staging-sa \
    --display-name="GitHub Actions Staging SA" \
    --project=$PROJECT_ID

export STAGING_SA_EMAIL="github-actions-staging-sa@${PROJECT_ID}.iam.gserviceaccount.com"

# Bind to develop branch
gcloud iam service-accounts add-iam-policy-binding "${STAGING_SA_EMAIL}" \
    --role="roles/iam.workloadIdentityUser" \
    --member="principalSet://iam.googleapis.com/projects/${PROJECT_NUMBER}/locations/global/workloadIdentityPools/github-pool/attribute.ref/refs/heads/develop" \
    --project=$PROJECT_ID

Then in your workflow:

- id: 'auth'
  name: 'Authenticate to Google Cloud'
  uses: 'google-github-actions/auth@v2'
  with:
    workload_identity_provider: 'projects/123456789/locations/global/workloadIdentityPools/github-pool/providers/github-provider'
    service_account: ${{ github.ref == 'refs/heads/main' && 'github-actions-prod-sa@project.iam.gserviceaccount.com' || 'github-actions-staging-sa@project.iam.gserviceaccount.com' }}

Verification and Testing

Test 1: Verify Token Exchange

Create a simple test workflow:

name: Test Workload Identity

on:
  workflow_dispatch:

permissions:
  id-token: write
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - id: 'auth'
        uses: 'google-github-actions/auth@v2'
        with:
          workload_identity_provider: 'projects/123456789/locations/global/workloadIdentityPools/github-pool/providers/github-provider'
          service_account: 'github-actions-sa@your-project-id.iam.gserviceaccount.com'
      
      - name: 'Verify Authentication'
        run: |
          gcloud auth list
          gcloud projects describe ${{ secrets.GCP_PROJECT_ID }}

Test 2: Audit Logs

Check Cloud Audit Logs to verify authentication:

gcloud logging read "protoPayload.methodName=GenerateAccessToken" \
    --limit=10 \
    --format=json \
    --project=$PROJECT_ID

Look for entries showing GitHub Actions successfully exchanging tokens.

Security Best Practices

1. Principle of Least Privilege

Grant only the minimum permissions needed:

# Instead of broad roles, use specific permissions
gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:${SA_EMAIL}" \
    --role="roles/run.developer"  # Instead of run.admin

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:${SA_EMAIL}" \
    --role="roles/cloudsql.client"  # Instead of cloudsql.admin for read-only access

2. Use Attribute Conditions Strictly

Always restrict which external identities can authenticate:

# Bad: Too permissive
--attribute-condition=""

# Good: Specific organization
--attribute-condition="assertion.repository_owner=='your-org'"

# Better: Specific repositories and branches
--attribute-condition="assertion.repository_owner=='your-org' && assertion.repository.startsWith('your-org/prod-') && assertion.ref=='refs/heads/main'"

3. Separate Service Accounts by Environment

Never use the same service account for production and staging:

✗ github-actions-sa → All environments
✓ github-actions-prod-sa → Production only
✓ github-actions-staging-sa → Staging only
✓ github-actions-dev-sa → Development only

4. Enable Audit Logging

Ensure Data Access audit logs are enabled:

# Create audit config
cat > audit-config.yaml <<EOF
auditConfigs:
- auditLogConfigs:
  - logType: ADMIN_READ
  - logType: DATA_READ
  - logType: DATA_WRITE
  service: iam.googleapis.com
EOF

gcloud projects set-iam-policy $PROJECT_ID audit-config.yaml

5. Monitor Token Exchange Activity

Set up monitoring alerts for suspicious activity:

# Create a log-based metric
gcloud logging metrics create workload-identity-failures \
    --description="Failed workload identity token exchanges" \
    --log-filter='protoPayload.methodName="GenerateAccessToken"
    AND protoPayload.status.code!=0'

# Create alert policy
gcloud alpha monitoring policies create \
    --notification-channels=CHANNEL_ID \
    --display-name="Workload Identity Failures" \
    --condition-display-name="High failure rate" \
    --condition-threshold-value=5 \
    --condition-threshold-duration=60s

6. Cloud SQL Security Best Practices

Implement these security measures for Cloud SQL:

# Enable automatic backups
gcloud sql instances patch production-db \
    --backup-start-time=03:00 \
    --enable-bin-log \
    --project=$PROJECT_ID

# Enable point-in-time recovery
gcloud sql instances patch production-db \
    --enable-point-in-time-recovery \
    --project=$PROJECT_ID

# Require SSL for all connections
gcloud sql instances patch production-db \
    --require-ssl \
    --project=$PROJECT_ID

# Enable database flags for security
gcloud sql instances patch production-db \
    --database-flags=\
cloudsql.iam_authentication=on,\
log_checkpoints=on,\
log_connections=on,\
log_disconnections=on,\
log_lock_waits=on,\
log_statement=ddl,\
log_min_duration_statement=1000 \
    --project=$PROJECT_ID

# Restrict network access (private IP only)
gcloud sql instances patch production-db \
    --no-assign-ip \
    --network=projects/$PROJECT_ID/global/networks/default \
    --project=$PROJECT_ID

Database User Security:

-- Revoke public schema privileges
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
REVOKE ALL ON DATABASE production FROM PUBLIC;

-- Create read-only role for analytics
CREATE ROLE analytics_readonly;
GRANT CONNECT ON DATABASE production TO analytics_readonly;
GRANT USAGE ON SCHEMA public TO analytics_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO analytics_readonly;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO analytics_readonly;

-- Create application role with limited privileges
CREATE ROLE app_user;
GRANT CONNECT ON DATABASE production TO app_user;
GRANT USAGE ON SCHEMA public TO app_user;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO app_user;
GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO app_user;

-- Assign IAM service account to role
GRANT app_user TO "github-actions-sa@project-id.iam";

Automated Security Scanning:

# Add to your GitHub workflow
- name: 'Scan Database for Security Issues'
  run: |
    # Check for overly permissive grants
    psql -h 127.0.0.1 -p 5432 -U dbuser -d production <<EOF
    SELECT 
      grantee, 
      string_agg(privilege_type, ', ') as privileges,
      table_schema,
      table_name
    FROM information_schema.table_privileges
    WHERE grantee = 'PUBLIC'
    GROUP BY grantee, table_schema, table_name;
    EOF
    
    # Check for weak passwords (if not using IAM auth)
    psql -h 127.0.0.1 -p 5432 -U dbuser -d production <<EOF
    SELECT usename 
    FROM pg_shadow 
    WHERE passwd IS NULL OR passwd = '';
    EOF

7. Secrets Rotation Strategy

Automate credential rotation for enhanced security:

# Create a rotation script
cat > rotate-db-password.sh <<'EOF'
#!/bin/bash
set -e

PROJECT_ID=$1
INSTANCE_NAME=$2
DB_USER=$3
SECRET_NAME=$4

# Generate new password
NEW_PASSWORD=$(openssl rand -base64 32)

# Update Cloud SQL user
gcloud sql users set-password $DB_USER \
    --instance=$INSTANCE_NAME \
    --password=$NEW_PASSWORD \
    --project=$PROJECT_ID

# Update Secret Manager
echo -n "$NEW_PASSWORD" | gcloud secrets versions add $SECRET_NAME \
    --data-file=- \
    --project=$PROJECT_ID

# Disable old secret versions (after grace period)
OLD_VERSIONS=$(gcloud secrets versions list $SECRET_NAME \
    --filter="state:ENABLED" \
    --format="value(name)" \
    --sort-by="~createTime" \
    --limit=5 \
    | tail -n +3)

for VERSION in $OLD_VERSIONS; do
    gcloud secrets versions disable $VERSION --secret=$SECRET_NAME --project=$PROJECT_ID
done

echo "Password rotated successfully"
EOF

chmod +x rotate-db-password.sh

# Schedule rotation with Cloud Scheduler
gcloud scheduler jobs create http db-password-rotation \
    --schedule="0 0 1 * *" \
    --uri="https://your-cloud-function-url/rotate-password" \
    --http-method=POST \
    --oidc-service-account-email=$SA_EMAIL \
    --project=$PROJECT_ID

Troubleshooting Common Issues

Issue 1: "Permission denied" when exchanging token

Symptom:

Error: google-github-actions/auth failed with: failed to generate Google Cloud access token: 
(400) {"error":"invalid_target","error_description":"The provided target service account is invalid"}

Solution: Verify the IAM binding:

gcloud iam service-accounts get-iam-policy $SA_EMAIL \
    --project=$PROJECT_ID \
    --flatten="bindings[].members" \
    --filter="bindings.role:roles/iam.workloadIdentityUser"

Ensure the principal matches your repository exactly.

Issue 2: "Attribute condition not satisfied"

Symptom:

Error: (403) Attribute condition not satisfied

Solution: Check your attribute condition matches the token claims:

# Update condition to be more permissive temporarily for debugging
gcloud iam workload-identity-pools providers update-oidc "github-provider" \
    --location="global" \
    --workload-identity-pool="github-pool" \
    --attribute-condition="" \
    --project=$PROJECT_ID

Then examine the actual token claims in audit logs and adjust your condition.

Issue 3: Missing id-token: write permission

Symptom:

Error: Unable to get ACTIONS_ID_TOKEN_REQUEST_URL env variable

Solution: Add to your workflow:

permissions:
  id-token: write
  contents: read

Issue 4: Insufficient permissions for service account

Symptom:

Error: (403) Permission denied on resource

Solution: Review and grant required roles:

# Check current roles
gcloud projects get-iam-policy $PROJECT_ID \
    --flatten="bindings[].members" \
    --filter="bindings.members:serviceAccount:${SA_EMAIL}"

# Add missing role
gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:${SA_EMAIL}" \
    --role="roles/REQUIRED_ROLE"

Issue 5: Cloud SQL Proxy Connection Timeout

Symptom:

Error: couldn't connect to <instance>: dial tcp 127.0.0.1:5432: connect: connection refused

Solution: Ensure the proxy has started and the service account has cloudsql.client role:

# Verify service account has Cloud SQL Client role
gcloud projects get-iam-policy $PROJECT_ID \
    --flatten="bindings[].members" \
    --filter="bindings.members:serviceAccount:${SA_EMAIL}" \
    --filter="bindings.role:roles/cloudsql.client"

# Grant if missing
gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:${SA_EMAIL}" \
    --role="roles/cloudsql.client"

# In your workflow, add more wait time
./cloud_sql_proxy -instances=$INSTANCE &
sleep 10  # Increase from 5 to 10 seconds

# Or check proxy logs
./cloud_sql_proxy -instances=$INSTANCE -verbose &

Issue 6: IAM Database Authentication Failures

Symptom:

psql: error: connection to server at "127.0.0.1", port 5432 failed: 
FATAL: password authentication failed for user "github-actions-sa@project.iam"

Solution: Verify IAM user exists and has proper grants:

# Check if IAM user exists
gcloud sql users list --instance=production-db --project=$PROJECT_ID

# Create IAM user if missing
gcloud sql users create github-actions-sa@$PROJECT_ID.iam \
    --instance=production-db \
    --type=CLOUD_IAM_SERVICE_ACCOUNT \
    --project=$PROJECT_ID

# Grant database permissions (connect via Cloud SQL Proxy first)
psql "host=127.0.0.1 port=5432 user=postgres dbname=production" <<EOF
GRANT CONNECT ON DATABASE production TO "github-actions-sa@$PROJECT_ID.iam";
GRANT USAGE ON SCHEMA public TO "github-actions-sa@$PROJECT_ID.iam";
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO "github-actions-sa@$PROJECT_ID.iam";
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO "github-actions-sa@$PROJECT_ID.iam";
EOF

Issue 7: Secret Manager Access Denied

Symptom:

Error: gcloud secrets versions access latest --secret="db-password"
ERROR: (gcloud.secrets.versions.access) PERMISSION_DENIED

Solution: Grant Secret Manager access:

# Grant access to specific secret
gcloud secrets add-iam-policy-binding db-password \
    --member="serviceAccount:${SA_EMAIL}" \
    --role="roles/secretmanager.secretAccessor" \
    --project=$PROJECT_ID

# Or grant project-wide access (less secure)
gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:${SA_EMAIL}" \
    --role="roles/secretmanager.secretAccessor"

Issue 8: Cloud SQL Instance Not Found

Symptom:

Error: instance does not exist or you are not authorized to access it

Solution: Verify instance name and permissions:

# List all Cloud SQL instances
gcloud sql instances list --project=$PROJECT_ID

# Describe specific instance
gcloud sql instances describe production-db --project=$PROJECT_ID

# Ensure correct connection name format: PROJECT_ID:REGION:INSTANCE_NAME
# Example: my-project:us-central1:production-db

Issue 9: Migration Script Fails Silently

Symptom: Workflow succeeds but migrations don't apply.

Solution: Add explicit error handling:

- name: 'Run Migrations with Error Handling'
  run: |
    set -e  # Exit on any error
    set -o pipefail  # Catch errors in pipes
    
    ./cloud_sql_proxy -instances=$INSTANCE_CONNECTION_NAME=tcp:5432 &
    PROXY_PID=$!
    
    # Ensure proxy cleanup on exit
    trap "kill $PROXY_PID 2>/dev/null || true" EXIT
    
    sleep 5
    
    DB_PASSWORD=$(gcloud secrets versions access latest --secret="db-password")
    export PGPASSWORD=$DB_PASSWORD
    
    # Run migration with verbose output
    psql -h 127.0.0.1 -p 5432 -U dbuser -d production \
      -v ON_ERROR_STOP=1 \
      -f migrations/schema.sql \
      2>&1 | tee migration.log
    
    # Check exit code explicitly
    if [ ${PIPESTATUS[0]} -ne 0 ]; then
      echo "Migration failed!"
      cat migration.log
      exit 1
    fi

Issue 10: Connection Pool Exhaustion

Symptom:

Error: remaining connection slots are reserved for non-replication superuser connections

Solution: Implement connection pooling and limits:

- name: 'Use Connection Pooling'
  run: |
    # Increase max_connections on Cloud SQL instance
    gcloud sql instances patch production-db \
      --database-flags=max_connections=100 \
      --project=$PROJECT_ID
    
    # Or use PgBouncer for connection pooling
    cat > pgbouncer.ini <<EOF
[databases]
production = host=127.0.0.1 port=5432 dbname=production

[pgbouncer]
pool_mode = transaction
max_client_conn = 100
default_pool_size = 20
reserve_pool_size = 5
EOF
    
    pgbouncer -d pgbouncer.ini
    
    # Connect through PgBouncer on port 6432
    psql -h 127.0.0.1 -p 6432 -U dbuser -d production -f migrations/schema.sql

Advanced Topics

Complete Infrastructure Provisioning with gcloud

Here's a complete script to provision all infrastructure using gcloud commands:

#!/bin/bash
# complete-setup.sh - Complete Workload Identity Federation setup script

set -e  # Exit on error

# Configuration variables
export PROJECT_ID="your-project-id"
export GITHUB_ORG="your-github-org"
export GITHUB_REPO="your-repo-name"
export REGION="us-central1"
export DB_INSTANCE_NAME="production-db"
export DB_NAME="production"
export DB_USER="dbuser"

# Colors for output
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
NC='\033[0m' # No Color

echo -e "${GREEN}Starting Workload Identity Federation setup...${NC}"

# Step 1: Enable required APIs
echo -e "${YELLOW}Enabling required APIs...${NC}"
gcloud services enable \
    iamcredentials.googleapis.com \
    cloudresourcemanager.googleapis.com \
    sts.googleapis.com \
    sqladmin.googleapis.com \
    secretmanager.googleapis.com \
    run.googleapis.com \
    cloudbuild.googleapis.com \
    artifactregistry.googleapis.com \
    --project=$PROJECT_ID

# Get project number
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format="value(projectNumber)")
echo -e "${GREEN}Project Number: $PROJECT_NUMBER${NC}"

# Step 2: Create Workload Identity Pool
echo -e "${YELLOW}Creating Workload Identity Pool...${NC}"
if gcloud iam workload-identity-pools describe "github-pool" \
    --location="global" \
    --project=$PROJECT_ID &>/dev/null; then
    echo -e "${GREEN}Pool already exists, skipping...${NC}"
else
    gcloud iam workload-identity-pools create "github-pool" \
        --location="global" \
        --display-name="GitHub Actions Pool" \
        --description="Identity pool for GitHub Actions workflows" \
        --project=$PROJECT_ID
    echo -e "${GREEN}✓ Pool created${NC}"
fi

# Step 3: Create Workload Identity Provider
echo -e "${YELLOW}Creating Workload Identity Provider...${NC}"
if gcloud iam workload-identity-pools providers describe "github-provider" \
    --location="global" \
    --workload-identity-pool="github-pool" \
    --project=$PROJECT_ID &>/dev/null; then
    echo -e "${GREEN}Provider already exists, skipping...${NC}"
else
    gcloud iam workload-identity-pools providers create-oidc "github-provider" \
        --location="global" \
        --workload-identity-pool="github-pool" \
        --display-name="GitHub Actions Provider" \
        --attribute-mapping="google.subject=assertion.sub,attribute.actor=assertion.actor,attribute.repository=assertion.repository,attribute.repository_owner=assertion.repository_owner,attribute.ref=assertion.ref" \
        --attribute-condition="assertion.repository_owner=='${GITHUB_ORG}'" \
        --issuer-uri="https://token.actions.githubusercontent.com" \
        --project=$PROJECT_ID
    echo -e "${GREEN}✓ Provider created${NC}"
fi

# Step 4: Create Service Accounts
echo -e "${YELLOW}Creating service accounts...${NC}"

# Production service account
if gcloud iam service-accounts describe github-actions-prod-sa@${PROJECT_ID}.iam.gserviceaccount.com \
    --project=$PROJECT_ID &>/dev/null; then
    echo -e "${GREEN}Production SA already exists, skipping...${NC}"
else
    gcloud iam service-accounts create github-actions-prod-sa \
        --display-name="GitHub Actions Production SA" \
        --description="Production deployment service account" \
        --project=$PROJECT_ID
    echo -e "${GREEN}✓ Production SA created${NC}"
fi

# Staging service account
if gcloud iam service-accounts describe github-actions-staging-sa@${PROJECT_ID}.iam.gserviceaccount.com \
    --project=$PROJECT_ID &>/dev/null; then
    echo -e "${GREEN}Staging SA already exists, skipping...${NC}"
else
    gcloud iam service-accounts create github-actions-staging-sa \
        --display-name="GitHub Actions Staging SA" \
        --description="Staging deployment service account" \
        --project=$PROJECT_ID
    echo -e "${GREEN}✓ Staging SA created${NC}"
fi

export PROD_SA_EMAIL="github-actions-prod-sa@${PROJECT_ID}.iam.gserviceaccount.com"
export STAGING_SA_EMAIL="github-actions-staging-sa@${PROJECT_ID}.iam.gserviceaccount.com"

# Step 5: Grant IAM permissions to service accounts
echo -e "${YELLOW}Granting IAM permissions...${NC}"

# Production permissions
for ROLE in "roles/run.admin" "roles/iam.serviceAccountUser" "roles/cloudsql.client" \
            "roles/storage.admin" "roles/secretmanager.secretAccessor"; do
    gcloud projects add-iam-policy-binding $PROJECT_ID \
        --member="serviceAccount:${PROD_SA_EMAIL}" \
        --role="$ROLE" \
        --condition=None \
        --quiet
done

# Staging permissions (more limited)
for ROLE in "roles/run.developer" "roles/cloudsql.client" \
            "roles/secretmanager.secretAccessor"; do
    gcloud projects add-iam-policy-binding $PROJECT_ID \
        --member="serviceAccount:${STAGING_SA_EMAIL}" \
        --role="$ROLE" \
        --condition=None \
        --quiet
done

echo -e "${GREEN}✓ IAM permissions granted${NC}"

# Step 6: Bind workload identity to service accounts
echo -e "${YELLOW}Binding workload identity...${NC}"

# Production: main branch only
gcloud iam service-accounts add-iam-policy-binding "${PROD_SA_EMAIL}" \
    --role="roles/iam.workloadIdentityUser" \
    --member="principalSet://iam.googleapis.com/projects/${PROJECT_NUMBER}/locations/global/workloadIdentityPools/github-pool/attribute.ref/refs/heads/main" \
    --project=$PROJECT_ID \
    --quiet

# Staging: develop branch
gcloud iam service-accounts add-iam-policy-binding "${STAGING_SA_EMAIL}" \
    --role="roles/iam.workloadIdentityUser" \
    --member="principalSet://iam.googleapis.com/projects/${PROJECT_NUMBER}/locations/global/workloadIdentityPools/github-pool/attribute.ref/refs/heads/develop" \
    --project=$PROJECT_ID \
    --quiet

echo -e "${GREEN}✓ Workload identity bindings created${NC}"

# Step 7: Create Artifact Registry repository
echo -e "${YELLOW}Creating Artifact Registry repository...${NC}"
if gcloud artifacts repositories describe apps \
    --location=$REGION \
    --project=$PROJECT_ID &>/dev/null; then
    echo -e "${GREEN}Repository already exists, skipping...${NC}"
else
    gcloud artifacts repositories create apps \
        --repository-format=docker \
        --location=$REGION \
        --description="Docker images for applications" \
        --project=$PROJECT_ID
    echo -e "${GREEN}✓ Artifact Registry created${NC}"
fi

# Step 8: Create Cloud SQL instance
echo -e "${YELLOW}Creating Cloud SQL instance (this may take 5-10 minutes)...${NC}"
if gcloud sql instances describe $DB_INSTANCE_NAME \
    --project=$PROJECT_ID &>/dev/null; then
    echo -e "${GREEN}Cloud SQL instance already exists, skipping...${NC}"
else
    gcloud sql instances create $DB_INSTANCE_NAME \
        --database-version=POSTGRES_15 \
        --tier=db-custom-2-7680 \
        --region=$REGION \
        --network=projects/$PROJECT_ID/global/networks/default \
        --no-assign-ip \
        --database-flags=cloudsql.iam_authentication=on,log_connections=on,log_disconnections=on \
        --backup-start-time=03:00 \
        --enable-bin-log \
        --enable-point-in-time-recovery \
        --maintenance-window-day=SUN \
        --maintenance-window-hour=4 \
        --project=$PROJECT_ID
    echo -e "${GREEN}✓ Cloud SQL instance created${NC}"
fi

# Step 9: Create database
echo -e "${YELLOW}Creating database...${NC}"
if gcloud sql databases describe $DB_NAME \
    --instance=$DB_INSTANCE_NAME \
    --project=$PROJECT_ID &>/dev/null; then
    echo -e "${GREEN}Database already exists, skipping...${NC}"
else
    gcloud sql databases create $DB_NAME \
        --instance=$DB_INSTANCE_NAME \
        --project=$PROJECT_ID
    echo -e "${GREEN}✓ Database created${NC}"
fi

# Step 10: Create IAM database users
echo -e "${YELLOW}Creating IAM database users...${NC}"

# Production IAM user
if gcloud sql users describe "${PROD_SA_EMAIL}" \
    --instance=$DB_INSTANCE_NAME \
    --project=$PROJECT_ID &>/dev/null; then
    echo -e "${GREEN}Production IAM user already exists, skipping...${NC}"
else
    gcloud sql users create "${PROD_SA_EMAIL}" \
        --instance=$DB_INSTANCE_NAME \
        --type=CLOUD_IAM_SERVICE_ACCOUNT \
        --project=$PROJECT_ID
    echo -e "${GREEN}✓ Production IAM user created${NC}"
fi

# Staging IAM user
if gcloud sql users describe "${STAGING_SA_EMAIL}" \
    --instance=$DB_INSTANCE_NAME \
    --project=$PROJECT_ID &>/dev/null; then
    echo -e "${GREEN}Staging IAM user already exists, skipping...${NC}"
else
    gcloud sql users create "${STAGING_SA_EMAIL}" \
        --instance=$DB_INSTANCE_NAME \
        --type=CLOUD_IAM_SERVICE_ACCOUNT \
        --project=$PROJECT_ID
    echo -e "${GREEN}✓ Staging IAM user created${NC}"
fi

# Step 11: Create secrets in Secret Manager
echo -e "${YELLOW}Creating secrets...${NC}"

# Generate a strong password (as fallback)
DB_PASSWORD=$(openssl rand -base64 32)

if gcloud secrets describe db-password \
    --project=$PROJECT_ID &>/dev/null; then
    echo -e "${GREEN}Secret already exists, skipping...${NC}"
else
    echo -n "$DB_PASSWORD" | gcloud secrets create db-password \
        --data-file=- \
        --replication-policy="automatic" \
        --project=$PROJECT_ID
    echo -e "${GREEN}✓ Database password secret created${NC}"
fi

# Grant access to secrets
gcloud secrets add-iam-policy-binding db-password \
    --member="serviceAccount:${PROD_SA_EMAIL}" \
    --role="roles/secretmanager.secretAccessor" \
    --project=$PROJECT_ID \
    --quiet

gcloud secrets add-iam-policy-binding db-password \
    --member="serviceAccount:${STAGING_SA_EMAIL}" \
    --role="roles/secretmanager.secretAccessor" \
    --project=$PROJECT_ID \
    --quiet

# Step 12: Enable audit logging
echo -e "${YELLOW}Configuring audit logging...${NC}"
cat > /tmp/audit-config.json <<EOF
{
  "auditConfigs": [
    {
      "service": "iam.googleapis.com",
      "auditLogConfigs": [
        {"logType": "ADMIN_READ"},
        {"logType": "DATA_READ"},
        {"logType": "DATA_WRITE"}
      ]
    },
    {
      "service": "cloudsql.googleapis.com",
      "auditLogConfigs": [
        {"logType": "ADMIN_READ"},
        {"logType": "DATA_READ"},
        {"logType": "DATA_WRITE"}
      ]
    }
  ]
}
EOF

# Note: Full audit config merge would require getting current policy first
echo -e "${YELLOW}Note: Audit logging configuration template created at /tmp/audit-config.json${NC}"
echo -e "${YELLOW}Apply manually if needed to preserve existing policies${NC}"

# Step 13: Create monitoring alerts
echo -e "${YELLOW}Creating monitoring metrics and alerts...${NC}"

# Workload Identity failures
gcloud logging metrics create workload-identity-failures \
    --description="Failed workload identity token exchanges" \
    --log-filter='protoPayload.methodName="GenerateAccessToken" AND protoPayload.status.code!=0' \
    --project=$PROJECT_ID &>/dev/null || echo -e "${YELLOW}Metric already exists${NC}"

# Cloud SQL connection failures
gcloud logging metrics create cloudsql-connection-failures \
    --description="Failed Cloud SQL connections" \
    --log-filter='resource.type="cloudsql_database" AND severity="ERROR"' \
    --project=$PROJECT_ID &>/dev/null || echo -e "${YELLOW}Metric already exists${NC}"

echo -e "${GREEN}✓ Monitoring metrics created${NC}"

# Step 14: Output important information
echo -e "${GREEN}========================================${NC}"
echo -e "${GREEN}Setup Complete!${NC}"
echo -e "${GREEN}========================================${NC}"
echo ""
echo -e "${YELLOW}Important Information:${NC}"
echo ""
echo "Workload Identity Provider:"
echo "  projects/$PROJECT_NUMBER/locations/global/workloadIdentityPools/github-pool/providers/github-provider"
echo ""
echo "Service Accounts:"
echo "  Production: $PROD_SA_EMAIL"
echo "  Staging: $STAGING_SA_EMAIL"
echo ""
echo "Cloud SQL Instance:"
echo "  Connection Name: $PROJECT_ID:$REGION:$DB_INSTANCE_NAME"
echo "  Database: $DB_NAME"
echo ""
echo "Artifact Registry:"
echo "  Repository: $REGION-docker.pkg.dev/$PROJECT_ID/apps"
echo ""
echo -e "${YELLOW}Next Steps:${NC}"
echo "1. Copy the Workload Identity Provider string above to your GitHub workflow"
echo "2. Add PROJECT_ID to your GitHub repository secrets"
echo "3. Configure database grants by connecting to Cloud SQL"
echo "4. Test the workflow with a deployment to develop branch (staging)"
echo "5. After validation, deploy to main branch (production)"
echo ""
echo -e "${GREEN}Save this output for reference!${NC}"

Using the Provisioning Script

Save the script and run it:

# Make executable
chmod +x complete-setup.sh

# Run with your configuration
./complete-setup.sh

Incremental Updates with gcloud

For updating specific components:

Update Workload Identity Provider:

# Add new attribute mapping
gcloud iam workload-identity-pools providers update-oidc "github-provider" \
    --location="global" \
    --workload-identity-pool="github-pool" \
    --attribute-mapping="google.subject=assertion.sub,attribute.actor=assertion.actor,attribute.repository=assertion.repository,attribute.repository_owner=assertion.repository_owner,attribute.ref=assertion.ref,attribute.environment=assertion.environment" \
    --project=$PROJECT_ID

# Update attribute condition
gcloud iam workload-identity-pools providers update-oidc "github-provider" \
    --location="global" \
    --workload-identity-pool="github-pool" \
    --attribute-condition="assertion.repository_owner=='your-org' && assertion.repository.startsWith('your-org/prod-')" \
    --project=$PROJECT_ID

Add New Service Account Binding:

# Bind new repository
gcloud iam service-accounts add-iam-policy-binding "${PROD_SA_EMAIL}" \
    --role="roles/iam.workloadIdentityUser" \
    --member="principalSet://iam.googleapis.com/projects/${PROJECT_NUMBER}/locations/global/workloadIdentityPools/github-pool/attribute.repository/your-org/new-repo" \
    --project=$PROJECT_ID

Update Cloud SQL Configuration:

# Increase instance size
gcloud sql instances patch production-db \
    --tier=db-custom-4-15360 \
    --project=$PROJECT_ID

# Add database flags
gcloud sql instances patch production-db \
    --database-flags=cloudsql.iam_authentication=on,max_connections=200,shared_buffers=2GB \
    --project=$PROJECT_ID

# Enable high availability
gcloud sql instances patch production-db \
    --availability-type=REGIONAL \
    --project=$PROJECT_ID

Cross-Project Access

Enable a service account in one project to be impersonated from another:

# Project A: Create workload identity pool
export PROJECT_A="project-a-id"
export PROJECT_B="project-b-id"
export PROJECT_A_NUMBER=$(gcloud projects describe $PROJECT_A --format="value(projectNumber)")

# Create pool in Project A
gcloud iam workload-identity-pools create "cross-project-pool" \
    --location="global" \
    --display-name="Cross-Project Pool" \
    --project=$PROJECT_A

# Create provider in Project A
gcloud iam workload-identity-pools providers create-oidc "cross-project-provider" \
    --location="global" \
    --workload-identity-pool="cross-project-pool" \
    --display-name="Cross-Project Provider" \
    --attribute-mapping="google.subject=assertion.sub,attribute.repository=assertion.repository" \
    --attribute-condition="assertion.repository_owner=='your-org'" \
    --issuer-uri="https://token.actions.githubusercontent.com" \
    --project=$PROJECT_A

# Create service account in Project B
gcloud iam service-accounts create cross-project-sa \
    --display-name="Cross-Project SA" \
    --project=$PROJECT_B

# Grant impersonation from Project A pool to Project B service account
gcloud iam service-accounts add-iam-policy-binding \
    "cross-project-sa@${PROJECT_B}.iam.gserviceaccount.com" \
    --role="roles/iam.workloadIdentityUser" \
    --member="principalSet://iam.googleapis.com/projects/${PROJECT_A_NUMBER}/locations/global/workloadIdentityPools/cross-project-pool/attribute.repository/your-org/your-repo" \
    --project=$PROJECT_B

# Grant Project B service account permissions in Project B
gcloud projects add-iam-policy-binding $PROJECT_B \
    --member="serviceAccount:cross-project-sa@${PROJECT_B}.iam.gserviceaccount.com" \
    --role="roles/cloudsql.client" \
    --project=$PROJECT_B

Cleanup Script

To remove all resources:

#!/bin/bash
# cleanup.sh - Remove all Workload Identity Federation resources

export PROJECT_ID="your-project-id"
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format="value(projectNumber)")

echo "Removing service account bindings..."
gcloud iam service-accounts remove-iam-policy-binding \
    "github-actions-prod-sa@${PROJECT_ID}.iam.gserviceaccount.com" \
    --role="roles/iam.workloadIdentityUser" \
    --member="principalSet://iam.googleapis.com/projects/${PROJECT_NUMBER}/locations/global/workloadIdentityPools/github-pool/attribute.ref/refs/heads/main" \
    --project=$PROJECT_ID

echo "Deleting workload identity provider..."
gcloud iam workload-identity-pools providers delete "github-provider" \
    --location="global" \
    --workload-identity-pool="github-pool" \
    --project=$PROJECT_ID \
    --quiet

echo "Deleting workload identity pool..."
gcloud iam workload-identity-pools delete "github-pool" \
    --location="global" \
    --project=$PROJECT_ID \
    --quiet

echo "Deleting service accounts..."
gcloud iam service-accounts delete "github-actions-prod-sa@${PROJECT_ID}.iam.gserviceaccount.com" \
    --project=$PROJECT_ID \
    --quiet

gcloud iam service-accounts delete "github-actions-staging-sa@${PROJECT_ID}.iam.gserviceaccount.com" \
    --project=$PROJECT_ID \
    --quiet

echo "Cleanup complete!"

Token Lifetime and Caching

Understand token lifetimes:

• OIDC tokens from GitHub: Valid for 10 minutes
• GCP access tokens: Valid for 1 hour by default
• The auth action caches tokens: Reuses valid tokens within the workflow

For long-running jobs, tokens are automatically refreshed.

Performance Optimization

1. Cache Authentication Step

The google-github-actions/auth action automatically caches credentials. Ensure subsequent steps reuse them:

steps:
  - id: 'auth'
    uses: 'google-github-actions/auth@v2'
    with:
      workload_identity_provider: '...'
      service_account: '...'
      token_format: 'access_token'  # Cache access token
      access_token_lifetime: '3600s'  # 1 hour

2. Parallel Job Authentication

Each job needs separate authentication:

jobs:
  deploy-frontend:
    runs-on: ubuntu-latest
    steps:
      - id: 'auth'
        uses: 'google-github-actions/auth@v2'
        # ... auth config
  
  deploy-backend:
    runs-on: ubuntu-latest
    steps:
      - id: 'auth'
        uses: 'google-github-actions/auth@v2'
        # ... same auth config

Both jobs authenticate independently in parallel.

Monitoring and Observability

Create Custom Dashboard

Monitor Workload Identity Federation usage:

# Create log-based metrics
gcloud logging metrics create wif-token-exchanges \
    --description="Workload Identity token exchanges" \
    --log-filter='protoPayload.methodName="GenerateAccessToken"'

gcloud logging metrics create wif-successful-exchanges \
    --description="Successful WIF exchanges" \
    --log-filter='protoPayload.methodName="GenerateAccessToken" AND protoPayload.status.code=0'

gcloud logging metrics create wif-failed-exchanges \
    --description="Failed WIF exchanges" \
    --log-filter='protoPayload.methodName="GenerateAccessToken" AND protoPayload.status.code!=0'

Query Recent Authentications

# Last 10 authentication attempts
gcloud logging read \
    'protoPayload.methodName="GenerateAccessToken"
    AND resource.labels.service_account_id:"github-actions-sa"' \
    --limit=10 \
    --format='table(timestamp,protoPayload.authenticationInfo.principalEmail,protoPayload.status.code)' \
    --project=$PROJECT_ID

Cost Considerations

Workload Identity Federation has no additional cost:

• ✓ Token exchange operations: Free
• ✓ Workload Identity Pools: Free
• ✓ Workload Identity Providers: Free
• ✓ IAM operations: Free (within quota)

You only pay for:

• Resources accessed by the service account (Cloud Run, BigQuery, etc.)
• Cloud Audit Logs storage (if enabled for Data Access logs)

Migration from Service Account Keys

If you're currently using service account keys, here's the migration path:

Step 1: Set up Workload Identity Federation (as shown above)

Step 2: Update workflows to use both methods temporarily

- id: 'auth'
  uses: 'google-github-actions/auth@v2'
  with:
    workload_identity_provider: 'projects/.../providers/github-provider'
    service_account: 'github-actions-sa@project.iam.gserviceaccount.com'
    # Fallback to key if WIF fails during migration
    credentials_json: ${{ secrets.GCP_SA_KEY }}

Step 3: Test thoroughly in staging

Step 4: Remove the fallback

- id: 'auth'
  uses: 'google-github-actions/auth@v2'
  with:
    workload_identity_provider: 'projects/.../providers/github-provider'
    service_account: 'github-actions-sa@project.iam.gserviceaccount.com'
    # No fallback - fully migrated to WIF

Step 5: Delete service account keys

# List keys
gcloud iam service-accounts keys list \
    --iam-account=$SA_EMAIL \
    --project=$PROJECT_ID

# Delete each key
gcloud iam service-accounts keys delete KEY_ID \
    --iam-account=$SA_EMAIL \
    --project=$PROJECT_ID

Step 6: Remove GitHub Secrets

Delete the GCP_SA_KEY secret from your repository settings.

Conclusion

Workload Identity Federation represents a significant security improvement over traditional service account keys. By implementing the steps in this guide, you've:

✓ Eliminated long-lived credentials from your CI/CD pipeline
✓ Reduced the risk of credential leakage
✓ Simplified credential rotation (it's now automatic)
✓ Improved audit trail with detailed token exchange logs
✓ Implemented fine-grained access control based on repository, branch, and actor
✓ Secured database access with Cloud SQL IAM authentication
✓ Automated database migrations without storing database credentials

While /dashboard is a sensible default for many SaaS applications, it isn't always what you need. Perhaps you are building an admin panel that lives at /panel, or maybe you are building a membership site or e-commerce store where the user should simply return to the homepage (/) after logging in.

If you dive into the official documentation, you might find yourself deep in bootstrap/app.php trying to customize the auth middleware logic. While that works, there is a much simpler configuration change that handles this in seconds.

The "Hard" Way: Middleware

Typically, the documentation guides developers to intercept the request within the bootstrap/app.php file to handle redirection for guests and authenticated users. This involves defining closures and logic that can clutter your bootstrap file if you only need a simple path change.

The "Easy" Way: Config Configuration

If your starter kit is powered by Laravel Fortify (which handles the backend authentication logic for kits like Jetstream), you don't need to touch your middleware or controllers. You can control this behavior directly from your configuration files.

Here is the one-line fix:

1. Navigate to config/fortify.php.
2. Locate the 'home' key (usually near the top of the file).
3. Change the value from RouteServiceProvider::HOME (or '/dashboard') to your desired path.

To redirect to the Homepage:

'home' => '/',

To redirect to a custom Admin Panel:

'home' => '/panel',

Why this works

Laravel Fortify uses this configuration value to determine where to send the user immediately after the authentication guard confirms their credentials. By changing it here, you ensure that the redirect is consistent across your application without having to write custom redirection logic in your controllers.

Don't overcomplicate your authentication flow. Before you start writing custom middleware logic in Laravel 12, check your config/fortify.php file. A simple string change is often all it takes to get your users exactly where they need to go.

Since I am quite comfortable with Tailwind CSS, I assumed customization would be a breeze. However, I am new to the Angular ecosystem and Material 3, and I face issues almost immediately regarding theming.

The Problem: Pre-built Palettes Are Limited

At setup time, I selected the standard Azure color palette. It looked decent enough for the toggle buttons initially, but as the UI evolved, I needed to change the color to match the specific primary color we were using for the rest of the project.

This turned out to be less straightforward than I expected.

I learned that Angular Material comes with several pre-built palettes, such as:

• red-palette
• blue-palette
• azure-palette
• violet-palette
• ...and about eight others.

While these cover the basics, none of them matched my specific branding needs. I needed a custom palette, not a generic preset.

The Solution: The Theme Generator

Digging deeper into the official documentation, I discovered that Angular provides a CLI tool to generate a custom palette based on your specific hex codes.

You can run the following command:

ng generate @angular/material:theme-color

This interactive tool asks you to define your primary, secondary, and neutral colors. Once finished, it produces a CSS (or SCSS) file with your generated theme variables.

The Missing Piece: How to Use It?

Here is where I got stuck. The tool generates the file—let's call it custom.css—but the documentation wasn't immediately clear on how to actually apply this new file to the project, specifically regarding where it fits into the existing material-theme.scss.

After some trial and error, I found the solution. You need to explicitly import your new custom styles into your main theme file.

1. Import the custom file Open your material-theme.scss file and add the use rule pointing to your generated file:

@use './app/styles/custom.css';

2. Disable the pre-built theme This is the crucial step. If you simply import your custom CSS, it might conflict with or be overridden by the default configuration you set up during installation.

You must comment out or remove the existing @include mat.theme block that references the old palette (like $azure-palette).

It should look something like this:

// html {
//   height: 100%;
//   @include mat.theme((
//     color: (
//       primary: mat.$azure-palette,
//       tertiary: mat.$azure-palette,
//     ),
//     typography: Roboto,
//     density: 0,
//   ));
// }

By removing the default theme inclusion and importing your generated custom.css, Angular Material will now respect the specific color definitions you generated via the CLI.

Note

You might notice that the hex color provided and the one set as primary color in the generated theme file are different. The tone changes slightly. If that's something which bothers you and you need the exact hex color as your primary color in the theme, then you can update the "primary palette" from the generated CSS file accordingly.

  /* Primary palette variables */
  --mat-sys-primary: light-dark(#5D688A, #bac3ff);
  --mat-sys-on-primary: light-dark(#ffffff, #1e2b68);
  --mat-sys-primary-container: light-dark(#dee1ff, #364280);
  --mat-sys-on-primary-container: light-dark(#051352, #dee1ff);
  --mat-sys-inverse-primary: light-dark(#bac3ff, #4e5a99);
  --mat-sys-primary-fixed: light-dark(#dee1ff, #dee1ff);
  --mat-sys-primary-fixed-dim: light-dark(#bac3ff, #bac3ff);
  --mat-sys-on-primary-fixed: light-dark(#051352, #051352);
  --mat-sys-on-primary-fixed-variant: light-dark(#364280, #364280);

The event took place on 8th October 2025 at the beautiful Maritim Resort.

I was honored to share the stage with some great panelists:

• Prof. (Dr.) Kiran Bhujun, Director of Tertiary Education & Scientific Research
• Shalini Bunwaree Nagdan, Founder of Unlock Synergies, Strategy Consultant, Corporate Trainer
• Yogesh Jankee, Vice President – Services, Dayforce

The discussion was moderated by Sareeta Nundloll Goundan, President of the PMI Mauritius Chapter and Managing Director of SSL Consulting Services. Sareeta also serves as a Board Director at ABC Banking.

During the panel, I was asked about whether Artificial Intelligence (AI) is replacing people and the fear of losing jobs. I explained that there are two ways to look at it. On one hand, AI can write code, so it’s easy to assume we no longer need developers but that’s not entirely true. AI isn’t replacing developers; it’s enhancing their productivity. Yes, a team that once needed ten developers for twenty projects might now manage with five, which can make it seem like AI is taking jobs. However, that same team of ten could now deliver five or more additional projects thanks to increased efficiency. My main point was that people need to learn how to learn, and learn fast in order to stay relevant in this evolving landscape. As Sareeta added, it’s equally important to be able to unlearn and relearn when the world changes.

A first PMI Conference Experience

I joined the PMI Chapter earlier this year and have attended a few of their meetups, but this was my first experience participating in the PMI Mauritius Conference. I’m glad I accepted the invitation as it was both insightful and energizing.

The conference gathered professionals from a variety of industries, creating a unique opportunity to exchange ideas beyond the traditional IT sphere. Engaging with people who approach challenges through different lenses was a refreshing experience indeed.

One of the attendees, Ashwini G. Surnam, Senior Manager – Talent Acquisition at Dayforce, shared her reflections on LinkedIn and highlighted key lessons from the panel discussion.

I am grateful to Sareeta for the opportunity to contribute to a meaningful dialogue and to my colleague and mentor, Eddy Lareine, for inspiring me to step out of the tech bubble and explore the world of Project Management.

At the close of the event, I had an engaging conversation with Billy S. Mwape, CIO of FNB Zambia and a mentor for the PMI Sub-Saharan Africa region.

We spoke about Africans building for Africa in Africa, a topic that resonates with both of us. I shared my own journey and the challenges I’ve faced setting up Linux mirrors across the African continent, an effort driven by the belief that local infrastructure empowers local innovation. Naturally, the conversation took a technical turn at times. Billy passionately advocates for putting Africans on the global stage, a vision I wholeheartedly share. We also reflected on our experiences at international conferences, and the rich contrasts we’ve observed while traveling abroad and exploring different cultures.

Putting together a conference like this, which is attended by hundreds of professionals is not an easy feat. I can imagine the countless volunteer hours that must have been put to make it happen. Therefore, kudos to the organising team and all volunteers involved, and the sponsors for backing such an event financially.

First things first, we needed a venue for the event and time was running short. I contacted the African Leadership College of Higher Education to see if they could provide the venue and they gladly accepted. Next was to find a date for the event. The International Programmers Day is usually celebrated on the 12th or 13th September (depending on leap years). This year, it was celebrated on the 13th of September. However, that also meant it was the second Saturday of the month, when the Mauritius Software Craftsmanship Community holds its monthly meetup. Then, a week later, i.e on the 20th of September, the Front-end Coders held their monthly meetup. Therefore, to avoid a clash of events on those dates, Mervyn agreed that we hold the Programmers Day on the last Saturday of September, i.e the 27th.

Mervyn created a WhatsApp group with people from the different user groups wishing to help. Soon after, many started pushing ideas, like Alex working on the event poster, Shelly drafting the agenda and Mervyn looking for a catering sponsor.

Finally, on the 27th of September, all user groups (except for the AWS User Group), came together at the African Leadership College of Higher Education, and they presented their user group activities, things they organised and achieved in the past, e.g participating in global events, and also sharing their plans for the future.

Alex Bissessur presented the Cloud Native Community Group – Mauritius, which is the local chapter of the Cloud Native Computing Foundation. He spoke about the group's meetups, activities, and projects that some of the community members are working on, and mentioned the group's upcoming event — Hacktoberfest!

For more details about the CNCG Mauritius – Hacktoberfest, ping Alex or join the CNCG Mauritius Telegram group.

I spoke at 2 p.m. on the openSUSE Project. I briefly covered the history of S.u.S.E since 1992 and the creation of openSUSE in 2005. I then explained that the openSUSE Project isn't a Linux distribution but a project that houses several distributions, like Leap, Leap Micro, Tumbleweed, MicroOS, Aeon and Kalpa, and also several other applications, like Open Build Service and OpenQA, just to name a few.

I spoke about the myriad ways that one can contribute to the project, with a special mention about the openSUSE mirrors that we've built in Mauritius.

openSUSE Mauritius is not a user group in the traditional sense. I explained that it is an umbrella of contributions to the upstream project by people from Mauritius.

The event ended around 3 p.m.

The Kubernetes Story

The story of GKE begins with Kubernetes (also known as K8s), an open-source system for managing containerized applications. Google originally developed and open-sourced Kubernetes in 2014, and it was later accepted by the Cloud Native Computing Foundation (CNCF) in 2016. Google's expertise in this area is rooted in its own experience, as the company has been running its services like Gmail, YouTube, and Search on containers since the early 2000s. With billions of containers launched every week, Google has been its own best customer, and it's this decade of expertise that it shares through GKE.

A Decade of Innovation

After 10 months of alpha/beta development, Google Kubernetes Engine (GKE), then known as Google Container Engine, was launched on August 26, 2015, as the world's first fully managed Kubernetes service. Its early success was demonstrated by customers like Niantic, whose game Pokémon GO came to life on GKE.

GKE's evolution over the years has been driven by new features and increased capabilities:

• 2017: GKE's node support was increased to 5,000, and the service was officially renamed from Google Container Engine to Google Kubernetes Engine.
• 2018: GKE was made available across both Google Cloud and on-premise environments, offering a consistent platform for hybrid cloud deployments.
• 2019: Google announced Anthos, which went multi-cloud, allowing customers to deploy and manage applications seamlessly across on-prem, public cloud, and multiple public clouds.
• 2020: GKE's node support was scaled up to 15,000 nodes, enabling customers like Bayer Crop Science to handle massive workloads.
• 2021: The launch of GKE Autopilot allowed developers to focus on their workloads by having Google manage the underlying infrastructure. Other features included GPU time-sharing and a blue-green upgrade mechanism for node pools.
• 2022: GKE introduced support for Arm workloads with Tau T2A VMs, giving customers more cost-effective options.

Companies like Signify, formerly Philips Lighting, have used GKE as their foundation for a decade. They've scaled their infrastructure to support a fleet of over 153 million connected light points, absorbing an explosion in traffic while guaranteeing global reliability and performance. Today, Signify is leveraging GKE for new workloads like platform engineering and AI, exploring how GKE can help them transform technical signals into actionable diagnostics.

As GKE looks toward its next decade, it remains focused on helping businesses innovate faster, stay agile, and handle increasingly complex workloads, especially with the rise of AI-powered application development.

By default, Ansible's "interpreter discovery" is set to auto. In this mode, Ansible automatically attempts to find a suitable Python interpreter on the remote host by checking common default locations, such as /usr/bin/python3, /usr/bin/python, and python. This feature simplifies initial setups, as you don't have to manually configure the Python path for every new host.

However, this convenience comes with a specific warning you might encounter during execution:

$ ansible node-1 -i inventory -m ping
[WARNING]: Platform linux on host node-1 is using the discovered Python interpreter at /usr/bin/python3.12, but future installation of another Python interpreter could change the
meaning of that path. See https://docs.ansible.com/ansible-core/2.18/reference_appendices/interpreter_discovery.html for more information.
node-1 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3.12"
    },
    "changed": false,
    "ping": "pong"
}

This warning is essentially a proactive message from Ansible. It's telling you that while it successfully found a Python interpreter at one of its default locations, there's a possibility that a future system update or new software installation could change which interpreter is linked to that path. This could lead to unexpected behavior or module failures in later runs.

Resolving the Warning

To eliminate this warning and ensure consistency, you have a few options. The most reliable method is to explicitly define the path to the Python interpreter you want Ansible to use. If the interpreter is installed at a specific, stable location (for example, /usr/bin/python3.12), you can set this path for a specific host or an entire group of hosts in your inventory file.

For example, in an INI-style inventory file:

[web_servers]
node-1 ansible_python_interpreter=/usr/bin/python3.12
node-2 ansible_python_interpreter=/usr/bin/python3.12

[database_servers]
node-3
node-4

[database_servers:vars]
ansible_python_interpreter=/usr/bin/python3.9

Alternatively, in a YAML-style inventory:

all:
  children:
    web_servers:
      hosts:
        node-1:
          ansible_python_interpreter: /usr/bin/python3.12
        node-2:
          ansible_python_interpreter: /usr/bin/python3.12
    database_servers:
      hosts:
        node-3:
        node-4:
      vars:
        ansible_python_interpreter: /usr/bin/python3.9

By doing this, you're locking in the exact interpreter path, and Ansible will no longer need to discover it, thus bypassing the warning.

If you don't want to specify the interpreter for each host, or you are certain that interpreter changes won't be an issue in your environment, you can configure Ansible to run in "auto_silent" mode. This mode instructs Ansible to still perform the automatic discovery but to suppress the warning message.

This configuration can be applied at different levels of precedence.

For global or user-specific configurations, you would add the following to your ansible.cfg file (either at /etc/ansible/ansible.cfg or ~/.ansible.cfg):

[defaults]
interpreter_python = auto_silent

For individual hosts or entire groups within your inventory file, you would use the ansible_python_interpreter variable like so:

[my_group]
host1 ansible_python_interpreter=auto_silent
host2 ansible_python_interpreter=auto_silent

[another_group:vars]
ansible_python_interpreter=auto_silent

By following these steps, you can ensure your Ansible runs are clean of the Python interpreter warning, leading to a smoother and more predictable automation workflow.

Among the many sessions and daily keynotes, I had the opportunity to host and moderate a panel discussion titled “How Much Cybersecurity is Enough?”, a timely topic given the rapidly evolving threat landscape and the growing role of AI, cloud, and regulatory frameworks in shaping security strategies. With a diverse panel of industry experts and a highly engaged audience, the session turned into a dynamic exchange of ideas, experiences, and practical insights.

I totally enjoyed hosting and sincerely hope that everyone who attended the session enjoyed as much.

The panelists were:

• Didier Samfat, PhD
  Cybersecurity Specialist | CISSP | CEH | CMNA
• Zeimm Auladin-Suhootoorah
  IT Manager at Gamma Civic Ltd
• Joe Van der Walt
  Founding Director at Kohde
• Sebastien Stormacq
  Principal Developer Advocate at Amazon Web Services

Dr Samfat emphasized the need to foster a strong culture of security awareness within organizations, supported by regular maturity assessments to uncover potential blind spots. Building on this, Zeimm provided practical, real-world perspectives on securing complex infrastructure while striking the right balance between innovation and budget constraints.

Joe highlighted the developer’s critical role in embedding security from the outset and the growing responsibility of AI builders to protect user data and privacy.

Adding a broader lens, Sébastien explored cloud-native security, the shared responsibility model, and the impact of evolving regulatory frameworks such as GDPR and the Cyber Resilience Act.

The room was filled to capacity, with an engaged and enthusiastic audience that actively participated by asking questions throughout the discussion. It's a shift from previous years’ format, as I invited audience interaction during the session rather than reserving all questions for a Q&A at the end.

Didier Adrien, IT Manager at SWAN, while commenting about security incidents in Mauritius, highlighted the importance of openly disclosing security incidents, stressing how such transparency benefits the broader community by fostering awareness, encouraging collaboration, and enabling collective learning to prevent similar threats.

On the day, i.e Saturday 12 July, I had a talk scheduled on "Container Runtimes."

It's been a while that I wanted to do this talk and dive into the lower realms of container management. We often talk about and demo container orchestration using high level tools, while not giving much attention to the underlying technologies. Therefore, my talk was like a primer on Linux namespaces and cgroups, followed by an introduction to container engines, mentioning the low-level and high-level ones.

Before my talk, I had a very interesting discussion with Renghen. As he was going through my slide deck, he noticed that I mentioned cgroups and he pointed out that all the modern features that we enjoy in container orchestration have been enabled thanks to cgroups v2 which was a complete overhaul of version 1, not just an update. Cgroup v2 provides more granular control over resource allocation, brought rootless features, simplifies resource management under one single unified hierarchy, among other improvements. I took note of that and included it when I spoke about control groups.

I shared a list of current actively developed container runtimes, among which I highlighted youki — a container runtime written in Rust. I co-maintain the youki package on the openSUSE Build Service and I wanted to share how I am using youki as an experiment to dive deeper and learn more about the low-level workings of container management.

Youki creates and starts a container but you will need a higher level container engine to actually manage your container resources. For that, I mentioned Podman. In fact, I asked how many in the room knew about Podman and to my surprise many raised their hands. It turns out that Podman is being heavily favoured over Docker by the development team at Accenture — something I was very glad to hear as a proponent of Podman since its inception. I did an introduction to Podman at the Middlesex University in 2019, the same year the stable version of Podman was released. Since then, Podman has always been my demo tool when talking about containers.

I happily shared a few SUSE geeko plushies with the attendees that were able to answer questions that I asked about container runtimes at the end of my presentation.