Add AWS RDS IAM Authentication Support to PostgreSQL Scaler

[joesteffee]

Summary

The PostgreSQL scaler currently only supports password-based authentication. This feature request proposes adding support for AWS RDS IAM database authentication, allowing KEDA to connect to RDS PostgreSQL instances using temporary IAM tokens instead of static passwords.

Motivation

AWS RDS IAM database authentication is becoming a security best practice for connecting to RDS instances. Benefits include:

• No need to store database passwords in Kubernetes secrets
• Automatic credential rotation (tokens expire after 15 minutes)
• Centralized access control through IAM policies
• Audit trail through CloudTrail
• Compliance with security standards that prohibit static passwords

Currently, users wanting to use KEDA with RDS PostgreSQL must either:

1. Use static passwords (security risk)
2. Implement complex workarounds (external scalers, proxy services)
3. Use hybrid approaches (passwords for KEDA, IAM for applications)

Detailed Design

Detection Logic

The PostgreSQL scaler should detect when IAM authentication should be used:

// When all conditions are met:
// 1. Running in AWS (IRSA available)
// 2. No password provided in metadata
// 3. Host appears to be RDS endpoint (*.rds.amazonaws.com)

Implementation Approach

1. Add AWS SDK dependencies to the PostgreSQL scaler
2. Check for IRSA credentials availability
3. Generate IAM token when connecting:

import (
    "github.com/aws/aws-sdk-go-v2/config"
    "github.com/aws/aws-sdk-go-v2/feature/rds/auth"
)

func (s *postgresqlScaler) getConnection() (*sql.DB, error) {
    password := s.metadata.password
    
    // If no password and running in AWS, try IAM auth
    if password == "" && s.isRDSHost() && hasIRSA() {
        token, err := s.generateIAMToken()
        if err != nil {
            return nil, fmt.Errorf("failed to generate IAM token: %w", err)
        }
        password = token
    }
    
    // Continue with normal connection logic
}

Configuration Example

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: postgres-iam-auth
spec:
  # No password needed when using IAM
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: postgresql-scaledobject
spec:
  triggers:
  - type: postgresql
    metadata:
      host: mydb.cluster-xyz.us-west-2.rds.amazonaws.com
      port: "5432"
      userName: keda_reader  # User must have rds_iam granted
      dbName: mydb
      sslmode: require
      # No password field - will use IAM auth
      query: "SELECT COUNT(*) FROM jobs WHERE status = 'pending'"
      targetQueryValue: "10"

IAM Setup Required

# IAM policy for KEDA operator
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["rds-db:connect"],
    "Resource": ["arn:aws:rds-db:region:account:dbuser:dbi-resource-id/db-user-name"]
  }]
}

# Database user setup
CREATE USER keda_reader WITH LOGIN;
GRANT rds_iam TO keda_reader;

Considerations

Connection Persistence

• IAM tokens expire after 15 minutes
• Existing connections remain valid after token expiry
• New connections require fresh tokens
• The scaler's connection pooling should handle this gracefully

Backward Compatibility

• Feature is opt-in (only activates when no password is provided)
• Existing password-based configurations continue to work
• No breaking changes to current users

Regional Support

• Initially support US/EU regions where RDS IAM is available
• Detect region from RDS endpoint or AWS environment

Alternatives Considered

1. External Scaler: Users can implement custom external scalers, but this adds complexity
2. Proxy Services: Running pgBouncer or similar, but adds another component to maintain
3. CloudWatch Metrics: Using CloudWatch instead of direct queries, but adds latency

Additional Context

This aligns with AWS best practices and would make KEDA more suitable for security-conscious environments. Many organizations are moving away from static passwords for compliance reasons.

Related AWS documentation:

• IAM Database Authentication
• Connecting using IAM auth

Implementation Plan

I'm willing to contribute this feature and will submit a pull request with:

1. Core IAM authentication logic
2. Unit tests
3. Documentation updates
4. Example configurations

Would love feedback from the maintainers on this approach!