Helm Chart Architecture

Directory Context

This document is part of the Overview Directory. See the Overview Directory Inventory for related resources.

Chart Relationship Diagram

graph TD
    subgraph "Core Infrastructure"
        A[scanner-infrastructure] --> A1[RBAC]
        A --> A2[Service Accounts]
        A --> A3[Token Management]
        A --> A4[Namespace]
    end

    subgraph "Common Components"
        B[common-scanner] --> B1[Scanning Scripts]
        B --> B2[SAF CLI Integration]
        B --> B3[Threshold Configuration]
    end

    subgraph "Scanning Approaches"
        C[standard-scanner] --> C1[Kubernetes API Scanning]
        D[distroless-scanner] --> D1[Debug Container Scanning]
        E[sidecar-scanner] --> E1[Sidecar Container Scanning]
    end

    A --> B
    B --> C
    B --> D
    B --> E

    classDef core fill:#f9f,stroke:#333,stroke-width:2px
    classDef common fill:#bbf,stroke:#333,stroke-width:2px
    classDef scanning fill:#bfb,stroke:#333,stroke-width:2px

    class A,A1,A2,A3,A4 core
    class B,B1,B2,B3 common
    class C,C1,D,D1,E,E1 scanning

Layered Architecture

Our Helm charts follow a layered architecture pattern with three distinct layers:

1. Core Infrastructure Layer (scanner-infrastructure)
2. Foundation for all scanning operations
3. RBAC and security model implementation
4. Service account and access control

5. Namespace management

6. Common Components Layer (common-scanner)

7. Reusable scanning utilities and scripts
8. SAF CLI integration for compliance validation
9. Threshold configuration for pass/fail criteria

10. Results processing and reporting

11. Scanning Approaches Layer (approach-specific charts)

12. Specialized components for each scanning approach
13. Test pods for demonstration and validation
14. Approach-specific configurations
15. Usage examples

Value Flow

Values flow through the chart hierarchy, allowing configuration at multiple levels:

graph TD
    A[User Values] --> B[standard-scanner Values]
    B --> C[common-scanner Values]
    C --> D[scanner-infrastructure Values]
    D --> E[Final Configuration]

This allows:

• Global values set at top level
• Approach-specific overrides
• Component-specific settings
• Local environment customization

Deployment Flow

The typical deployment flow involves these steps:

sequenceDiagram
    participant User
    participant Helm
    participant K8s as Kubernetes
    participant Scanner

    User->>Helm: Install Chart
    Helm->>K8s: Create Resources
    User->>K8s: Generate Tokens
    User->>Scanner: Run Scan
    Scanner->>K8s: Access Container
    Scanner->>User: Return Results

1. User installs Helm chart
2. Helm creates Kubernetes resources
3. User generates short-lived tokens
4. User runs scanning operation
5. Scanner accesses container via K8s API
6. Results returned to user

Integration Points

Our charts provide integration points with external systems:

graph TD
    subgraph "Integration Points"
        Charts[Helm Charts] --> CI[CI/CD Systems]
        Charts --> SM[Secret Management]
        Charts --> LO[Logging/Monitoring]
        Charts --> CMDB[CMDB/Inventory]
    end

Key integration points:

• CI/CD Systems: Pipeline integration
• Secret Management: External secrets for tokens
• Logging/Monitoring: Result tracking and alerting
• CMDB/Inventory: Asset tracking and management

Chart Dependencies

Formal Helm chart dependencies are defined in Chart.yaml files:

Chart	Dependencies
scanner-infrastructure	None
common-scanner	scanner-infrastructure
standard-scanner	common-scanner
distroless-scanner	common-scanner
sidecar-scanner	common-scanner

These dependencies ensure proper installation order and value inheritance.