Use custom DB roles in EventGate Lambdas

[tmikula-dev]

Summary

Currently, all EventGate Lambdas connect to the database using the postgres superuser. This is a significant security anti-pattern — the application should use least-privilege, role-specific database credentials instead of a superuser account.

Problem

• Every Lambda function uses the postgres user for DB access, regardless of what operations it actually performs.
• A compromised or buggy Lambda currently has full superuser access to the database (schema changes, other roles' data, etc.), far beyond what it needs.
• This is effectively the worst-case DB security posture for the application.

Proposed Change

• Update Lambdas to authenticate using the appropriate custom DB role(s) instead of postgres.
• Custom role credentials are (or will be) stored in AWS Secrets Manager (see companion infrastructure issue in cps-eventbus-gateway for provisioning these secrets).
• Pass the relevant Secrets Manager secret ARN into each Lambda so it can retrieve its DB credentials at runtime — likely via an environment variable (e.g. DB_SECRET_ARN), then resolved through the AWS SDK/Secrets Manager client during cold start or connection setup.
• Ensure Lambda IAM roles are granted secretsmanager:GetSecretValue scoped to only the specific secret(s) they need.
• Update DB connection/init code to fetch the username/password from the resolved secret instead of using hardcoded/postgres credentials.

Acceptance Criteria

• Lambdas no longer connect to the database as postgres.
• Each Lambda uses the custom role appropriate to its function/permissions needs.
• Secret ARN(s) are passed into Lambdas via environment variable(s).
• Lambda IAM permissions are scoped to only the secret(s) they require (least privilege).
• DB connection logic updated to fetch credentials from Secrets Manager at runtime.

Dependencies

• https://github.com/absa-group/cps-eventbus-gateway/issues/176