Cloud Security - WAF - AWS

[ngrkajac]

Overview

This epic tracks the implementation of AWS Web Application Firewall (WAF) and Certificate Manager integration for Kyma Cloud Manager. The goal is to enable declarative management of AWS security resources through Kubernetes Custom Resources, allowing developers to protect their workloads using GitOps workflows without requiring AWS Console access.

Related GitHub Issues

Implementation Issues

• AWS WAF WebACL Management via Kyma Cloud Manager #1776 - AWS WAF WebACL Management via Kyma Cloud Manager (AwsWebAcl CRD)
• AWS ACM Certificate Import Management via Kyma Cloud Manager #1777 - AWS ACM Certificate Import Management via Kyma Cloud Manager (AwsCertificate CRD)
• TBD - AWS IPSet Management (AwsIPSet CRD)
• TBD - AWS Load Balancer Controller enablement in kyma-infrastructure-manager
• TBD - Configurable Service Type for Istio IngressGateway (istio-module)

POC Documentation Issues

• POC: AWS WAF (ALB) + Istio Ingress – End-to-End TLS with SNI #1775 - POC: AWS WAF (ALB) + Istio Ingress – End-to-End TLS with SNI
• POC: AWS WAF and ALB with TLS Re-encryption to NGINX Backend #1774 - POC: AWS WAF and ALB with TLS Re-encryption to NGINX Backend
• POC: Exposing Istio Ingress Gateway via AWS ALB (HTTP) #1715 - POC: Exposing Istio Ingress Gateway via AWS ALB (HTTP)

Background

Kyma workloads on AWS require Layer 7 security protection through AWS WAF and managed TLS certificates through AWS Certificate Manager (ACM). Currently, these resources must be manually provisioned and managed through the AWS Console or CLI, with ARNs manually copied into Kubernetes Ingress annotations.

Target Architecture:

Internet → ALB (AWS WAF + ACM Certificate) → Istio IngressGateway → Application
         ↑                                    ↑
         Managed by Cloud Manager            Managed by Kyma

Components

1. AWS WAF WebACL Management via Kyma Cloud Manager (AwsWebAcl)

2. AWS IPSet Management (AwsIPSet CRD)

Status: Planned 📋

Description: Separate cluster-scoped CRD for managing reusable IP address sets that can be referenced by WebACL rules.

Key Features:

• IPV4 and IPV6 support
• CIDR block definitions
• Cross-resource references from WebACL rules
• Independent lifecycle management

API Example:

apiVersion: cloud-resources.kyma-project.io/v1beta1
kind: AwsIPSet
metadata:
  name: corporate-ips
spec:
  ipAddressVersion: IPV4
  addresses:
    - 203.0.113.0/24
    - 198.51.100.10/32
status:
  arn: arn:aws:wafv2:us-east-1:123456789012:regional/ipset/corporate-ips/xyz789
  id: xyz789

Integration with WebACL:

rules:
  - name: allow-corporate-ips
    statement:
      ipSetReference:
        name: corporate-ips  # References AwsIPSet resource

3. AWS ACM Certificate Import Management via Kyma Cloud Manager

Key Design Decisions

1. MetricName Strategy

Status: Deferred - To be decided later

Context:

• AWS WAF publishes metrics to CloudWatch via visibilityConfig.metricName
• Multiple Shoots can share same AWS account
• Multiple WebACLs per Shoot are common
• AWS tags do NOT appear as CloudWatch dimensions
• Decision on metrics collection strategy (including metricName defaulting) will be made separately

Options Under Consideration:

1. Customer-defined only (required)
2. Customer-defined with default (optional)
3. Hard-coded to Shoot name
4. Hard-coded to static value

Note: The visibilityConfig field will be included in the API for AWS WAF compatibility, but the strategy for metrics collection and aggregation will be determined in a separate design phase.

2. IPSet as Separate Resource

Decision: IPSet managed as separate AwsIPSet CRD, referenced via object reference

Reason:

• Reusable across multiple WebACLs
• Independent lifecycle management
• Kubernetes-native object reference pattern (name only, cluster-scoped)
• Prevents deletion of referenced IPSets via finalizers

3. Logical Operators with Limited Nesting

Decision: Support And/Or/Not with limited nesting levels using numbered statement types

Approach: Use explicit statement types per nesting level to avoid Kubernetes API circular reference limitation:

• AwsWebAclStatement - Level 0 (root)
• AwsWebAclStatement1 - Level 1
• AwsWebAclStatement2 - Level 2 (if supported)

Recommendation: Start with 1 nesting level (80% of use cases)

4. Resources are Cluster-Scoped

Decision: All AWS WAF and ACM resources are cluster-scoped (no namespace)

Reason:

• Aligns with cloud-resources API pattern
• Object references use name field only (no namespace)

5. AssociationConfig Omitted

Decision: AssociationConfig field not supported in initial implementation

Reason:

• Cloud Manager WebACLs exclusively used with ALB
• ALB has fixed 8KB request body inspection limit
• AssociationConfig only applies to CloudFront, API Gateway, Cognito, etc.

Related Feature Requests

1. AWS Load Balancer Controller in Gardener Shoots

Component: kyma-infrastructure-manager

Issue: Gardener shoot clusters on AWS don't have AWS Load Balancer Controller enabled by default

Request: Enable AWS Load Balancer Controller via GardenerCluster CR:

apiVersion: infrastructuremanager.kyma-project.io/v1
kind: GardenerCluster
spec:
  shoot:
    provider:
      type: aws
      controlPlaneConfig:
        loadBalancerController:
          enabled: true

Benefit: Enables ALB Ingress with WAF integration without manual ALB setup

2. Configurable Service Type for Istio IngressGateway

Component: istio-module (operator.kyma-project.io)

Issue: Istio IngressGateway service type is hardcoded to LoadBalancer, which creates security bypass when using ALB + WAF

Current Problem:

Client → ALB + WAF → Istio IngressGateway (NodePort)     ✓ Protected
Client → Istio LoadBalancer                               ✗ Bypasses WAF

Request: Allow configuration of service type through Istio CR:

apiVersion: operator.kyma-project.io/v1alpha2
kind: Istio
metadata:
  name: default
  namespace: kyma-system
spec:
  components:
    ingressGateway:
      k8s:
        serviceType: NodePort  # or LoadBalancer (default), ClusterIP

Benefit:

• Ensures ALL traffic flows through WAF-protected ALB (no bypass route)
• Eliminates unnecessary LoadBalancer resource and cost
• Supports security architectures requiring centralized ingress inspection
• Required for secure AWS WAF integration

Security Impact: Without NodePort configuration, the LoadBalancer service creates a direct public endpoint that bypasses WAF protection entirely, exposing applications to the internet without security filtering.

References

AWS Documentation

• AWS WAF Developer Guide
• CreateWebACL API Reference
• AWS WAF CloudWatch Metrics
• AWS Certificate Manager
• AWS Load Balancer Controller

Gardener Documentation

• Gardener AWS Extension