Component Microstacks

[rshade]

This pull request introduces several changes across multiple files, primarily focusing on enhancing Kubernetes components, adding new features to the OpenSearch and Squid configurations, and improving documentation for the EKS installer. The most significant updates include the addition of environment variables for OpenSearch, the implementation of a new Squid component, and expanded documentation for the EKS microstack architecture.

Kubernetes Component Enhancements:

• components-microstacks/index.ts: Added imports for Kubernetes Pulumi types and initialized empty environment variable arrays for console and API configurations.
• components-microstacks/openSearch.ts: Added envVars property to the OpenSearch class and populated it with relevant environment variables, including PULUMI_SEARCH_DOMAIN, PULUMI_SEARCH_USER, and PULUMI_SEARCH_PASSWORD. Fixed a hardcoded password by using args.intitialAdminPassword. [1] [2] [3]

Squid Component Implementation:

• components-microstacks/squid/squid.conf: Added a detailed Squid configuration file defining access control lists, ports, and caching behavior.
• components-microstacks/squid/squid.ts: Created a new Squid class to manage Squid deployment in Kubernetes. This includes configuration maps, persistent volume claims, services, and deployments with initialization containers for folder permissions.

Documentation Improvements:

• eks-hosted-microstacks/README.md: Added an introductory note about breaking the EKS installer into smaller stacks.
• eks-hosted/README.md: Expanded documentation on the microstack architecture, including deployment instructions, stack dependencies, and handling existing infrastructure. Improved formatting for better readability. [1] [2] [3]

[claude]

Claude finished @rshade's task —— View job

---

PR Review: Component Microstacks

I've completed a thorough review of this PR focused on Pulumi Infrastructure-as-Code best practices, security, and production readiness.

Review Tasks:

• Analyze component-extraction-plan.md for architectural decisions
• Review OpenSearch component changes and environment variable handling
• Evaluate new Squid component implementation
• Check documentation updates and consistency
• Assess security and production readiness
• Validate deployment patterns and backwards compatibility

🎯 Overall Assessment

This PR introduces a well-planned component extraction strategy for the EKS installer, moving toward shared, reusable Kubernetes components. The architectural approach is sound, but there are several production readiness concerns that should be addressed.

🏗️ Architectural Review

Strengths:

• Well-documented extraction plan: component-extraction-plan.md provides excellent strategic direction for component reusability across cloud platforms
• Modular design: Breaking down monolithic EKS deployments into shared components follows good separation of concerns
• Cloud-agnostic approach: Focus on Kubernetes-native resources that can work across AWS, Azure, and GCP

Areas for improvement:

• The extraction plan is comprehensive but should include migration timeline and risk assessment
• Consider creating interfaces/contracts for component compatibility to prevent breaking changes

🔍 Component-Specific Findings

OpenSearch Component (components-microstacks/openSearch.ts)

Critical Issues:

1. Cloud-specific hardcoding (Line 112):

   "cloud.google.com/neg": '{"ingress": true}'

   This GCP-specific annotation violates the cloud-agnostic design principle.

2. Type conversion issue (Line 143):

   value: args.intitialAdminPassword.toString()

   Using .toString() on Input<string> will result in "[object Object]" instead of the actual password value.

3. Typo in parameter name: intitialAdminPassword should be initialAdminPassword (Lines 14, 72, 118, 143)

Recommendations:

// Fix the environment variable to properly handle Pulumi Input types
{
    name: "PULUMI_SEARCH_PASSWORD",
    value: pulumi.output(args.initialAdminPassword).apply(pwd => pwd)
}

// Make service annotations configurable
service: {
    type: "NodePort",
    annotations: args.serviceAnnotations || {}
}

Squid Component (components-microstacks/squid/squid.ts)

Critical Issues:

1. Hardcoded file path (Line 20):

   const conf = fs.readFileSync('./squid.conf', 'utf-8');

   This will fail unless the component is called from the exact directory containing the file.

2. Missing resource requirements: The Squid deployment has empty resources: {} (Line 136), which can lead to resource starvation in production.

3. Security concern: Using ubuntu/squid:edge tag (Lines 113, 128) is not production-safe as it's a moving target.

Recommendations:

// Fix file path resolution
const conf = fs.readFileSync(path.join(__dirname, './squid.conf'), 'utf-8');

// Add proper resource limits
resources: {
    requests: {
        memory: "128Mi",
        cpu: "100m"
    },
    limits: {
        memory: "256Mi", 
        cpu: "200m"
    }
}

// Use pinned version instead of edge
image: "ubuntu/squid:5.7"

Squid Configuration (components-microstacks/squid/squid.conf)

Security Assessment:

• Configuration follows standard proxy security practices with appropriate ACLs
• Port restrictions are properly implemented (Safe_ports, SSL_ports)
• Cache directory configuration is reasonable for the use case

📚 Documentation Review

Positive changes:

• Clear deprecation notice for old EKS installer
• Well-structured explanation of microstack benefits
• Good documentation of deployment dependencies

Improvement needed:

• eks-hosted-microstacks/README.md is too minimal - should follow the pattern of other platform READMEs with architecture diagrams and detailed setup instructions

🔒 Security & Production Readiness

Critical Security Issues:

1. Plaintext password exposure: OpenSearch password passed as plain environment variable
2. Unpinned container images: Using :edge tags in production
3. Missing resource limits: Can lead to resource exhaustion

Production Readiness Issues:

1. Hardcoded paths: Component will fail when used from different directories
2. Type safety: Input type handling issues could cause runtime failures
3. Cloud specificity: Violates the stated cloud-agnostic design goal

🚀 Deployment Pattern Validation

Backwards Compatibility:

• ✅ Existing EKS deployments won't be affected (uses separate directory)
• ✅ Progressive migration approach allows gradual adoption
• ⚠️ Component interfaces should be formalized to prevent future breaking changes

Microstack Architecture:

• ✅ Follows established patterns from the extraction plan
• ✅ Maintains separation of concerns
• ⚠️ Component dependencies need clearer documentation

🔧 Recommendations for Production Deployment

1. Fix OpenSearch type handling and remove cloud-specific annotations
2. Resolve Squid file path and add resource limits with pinned image versions
3. Implement proper secret management for sensitive values
4. Add component interface contracts to prevent breaking changes
5. Expand eks-hosted-microstacks documentation with setup instructions and architecture diagrams

📊 Code Quality Score: 6/10

Strengths: Good architectural vision, clear extraction strategy, modular design
Concerns: Security issues, production readiness gaps, type safety problems

This PR shows excellent strategic thinking but needs the production readiness issues addressed before merge. The component extraction approach is sound and will provide significant value once the technical issues are resolved.