Validation Status

Components

Component	Validation Method	Status	Notes
Kubernetes manifests	kubectl apply --dry-run	✅ Validated	All manifests validated locally
Terraform modules	terraform validate	✅ Validated	All modules pass validation (GCP and AWS)
Terraform plan (GCP)	terraform plan	⚠️ Reviewed	Requires GCP credentials
Terraform plan (AWS)	terraform plan	⚠️ Reviewed	Requires AWS credentials
GCP resources	Requires deployment	⚠️ Reviewed	Not deployed to GCP
AWS resources	Requires deployment	⚠️ Reviewed	Not deployed to AWS
OAuth2 Proxy	Local validation	✅ Validated	Manifest validated, requires OAuth provider for full test
Cloud SQL Proxy (GCP)	Local validation	✅ Validated	Manifest validated, requires Cloud SQL for full test
RDS Proxy (AWS)	Local validation	✅ Validated	Manifest validated, requires RDS for full test
Kong API Gateway	Local validation	✅ Validated	Manifest validated, can be tested locally
SAML Integration	Documentation	⚠️ Reviewed	Documentation provided, requires IdP for testing
LDAP Integration	Documentation	⚠️ Reviewed	Documentation provided, requires LDAP server for testing
External Database	Documentation	⚠️ Reviewed	Documentation provided, requires external DB for testing
Connection Pooling	Documentation	⚠️ Reviewed	Documentation provided, requires database for testing
GCP API Gateway	Documentation	⚠️ Reviewed	Documentation provided, requires GCP API Gateway setup
Istio Service Mesh	Documentation	⚠️ Reviewed	Documentation provided, requires Istio installation

Multi-Cloud Support

This lab supports two deployment options:

1. GCP (GKE) - GKE cluster with Cloud SQL
2. AWS (EKS) - EKS cluster with RDS

Validation status applies to both providers unless otherwise noted. Authentication, API Gateway, and Service Mesh patterns are cloud-agnostic.

How to Validate

Local Validation

# Validate Kubernetes manifests
kubectl apply --dry-run=client -f auth-integration/oauth-proxy/oauth2-proxy.yaml
kubectl apply --dry-run=client -f database-connectivity/cloud-sql-proxy/cloud-sql-proxy.yaml
kubectl apply --dry-run=client -f database-connectivity/rds-proxy/rds-proxy.yaml
kubectl apply --dry-run=client -f api-gateway/kong-example/kong-deployment.yaml

# Validate Terraform
cd labs/07-integration-patterns
terraform init
terraform validate
terraform fmt -check

Cloud Validation (GCP)

# Requires GCP project and credentials
cd labs/07-integration-patterns
cp terraform.tfvars.example terraform.tfvars
# Set cloud_provider = "gcp" and configure GCP settings

terraform plan
terraform apply

# Get credentials
terraform output get_credentials_command

# Deploy integration patterns
kubectl apply -f auth-integration/oauth-proxy/oauth2-proxy.yaml
kubectl apply -f database-connectivity/cloud-sql-proxy/cloud-sql-proxy.yaml
kubectl apply -f api-gateway/kong-example/kong-deployment.yaml

# Validate
./scripts/validate.sh

Cloud Validation (AWS)

# Requires AWS account and credentials
cd labs/07-integration-patterns
cp terraform.tfvars.example terraform.tfvars
# Set cloud_provider = "aws" and configure AWS settings

terraform plan
terraform apply

# Get credentials
terraform output get_credentials_command

# Deploy integration patterns
kubectl apply -f auth-integration/oauth-proxy/oauth2-proxy.yaml
kubectl apply -f database-connectivity/rds-proxy/rds-proxy.yaml
kubectl apply -f api-gateway/kong-example/kong-deployment.yaml

# Validate
./scripts/validate.sh

Integration-Specific Validation

OAuth2 Proxy

Requirements:

• OAuth provider (Google, GitHub, etc.)
• Client ID and Secret
• Domain with DNS configured

Validation:

1. Deploy OAuth2 Proxy
2. Configure OAuth provider
3. Access application via proxy
4. Verify authentication flow

Cloud SQL Proxy (GCP)

Requirements:

• Cloud SQL instance
• Service account with permissions
• Workload Identity configured

Validation:

1. Create Cloud SQL instance (set create_database = true)
2. Deploy Cloud SQL Proxy
3. Connect from application pod
4. Execute test query

RDS Proxy (AWS)

Requirements:

• RDS instance
• RDS Proxy (optional, set create_rds_proxy = true)
• Security groups configured

Validation:

1. Create RDS instance with proxy (set create_database = true and create_rds_proxy = true)
2. Get RDS Proxy endpoint: terraform output aws_rds_proxy_endpoint
3. Update rds-proxy.yaml with endpoint
4. Deploy RDS Proxy manifest
5. Connect from application pod
6. Execute test query

Kong API Gateway

Requirements:

• Kubernetes cluster
• Backend service to route to

Validation:

1. Deploy Kong
2. Configure routes
3. Access backend via Kong
4. Verify routing and plugins

SAML/LDAP

Requirements:

• Identity provider (SAML) or LDAP server
• Customer-specific configuration

Validation:

• Documentation provided
• Requires customer environment for testing
• Follow discovery questions guide

Integration Pattern Status

Authentication Patterns

• OAuth2 Proxy: ✅ Manifest validated, requires OAuth provider for full test (cloud-agnostic)
• SAML: ⚠️ Documentation provided, requires IdP for testing (cloud-agnostic)
• LDAP/AD: ⚠️ Documentation provided, requires LDAP server for testing (cloud-agnostic)

Database Patterns

• Cloud SQL Proxy (GCP): ✅ Manifest validated, requires Cloud SQL for full test
• RDS Proxy (AWS): ✅ Manifest validated, requires RDS for full test
• External Database: ⚠️ Documentation provided, requires external DB for testing (cloud-agnostic)
• Connection Pooling: ⚠️ Documentation provided, requires database for testing (cloud-agnostic)

API Gateway Patterns

• Kong: ✅ Manifest validated, can be tested locally (cloud-agnostic)
• GCP API Gateway: ⚠️ Documentation provided, requires GCP API Gateway setup (GCP only)

Service Mesh

• Istio: ⚠️ Documentation provided, requires Istio installation (cloud-agnostic)

Provider-Specific Notes

GCP (Cloud SQL)

• ✅ Cloud SQL Proxy: Validated via Terraform configuration
• ✅ Workload Identity: Validated via configuration
• ⚠️ Database Connectivity: Requires deployment to test

AWS (RDS)

• ✅ RDS Module: Validated via Terraform configuration
• ✅ RDS Proxy: Validated via Terraform configuration
• ✅ Security Groups: Validated via configuration
• ⚠️ Database Connectivity: Requires deployment to test

Notes

Partial Validation

Many integration patterns require external services (OAuth providers, databases, etc.) that cannot be fully validated in a local environment. These patterns are:

1. Documented: Comprehensive documentation provided
2. Manifest Validated: Kubernetes manifests validated locally
3. Require External Services: Need customer-specific services for full testing

Customer-Specific Configurations

Integration patterns often require customer-specific configurations:

• OAuth client credentials
• SAML IdP details
• LDAP server information
• Database connection strings
• VPN/network configurations

These are documented in discovery questions guides.

Community Validation

If you've deployed this lab successfully, please:

1. Open an issue confirming successful deployment
2. Note which integration patterns you tested
3. Note your:
   • Provider (GCP or AWS)
   • Region/zone
   • Any modifications made
4. Confirm integration patterns are working
5. Update this file via PR if appropriate

Community Validation Results

• GCP: ⏳ Awaiting community validation
• AWS: ⏳ Awaiting community validation

Status Legend

• ✅ Validated - Tested and confirmed working
• ⏳ Pending - Not yet validated
• ⚠️ Reviewed - Code reviewed but not deployed/tested
• ❌ Failed - Validation failed (see notes)