Skip to content

Mascore 16861 - #573

Draft
amitpandey0217 wants to merge 21 commits into
mainfrom
MASCORE-16861
Draft

Mascore 16861#573
amitpandey0217 wants to merge 21 commits into
mainfrom
MASCORE-16861

Conversation

@amitpandey0217

Copy link
Copy Markdown
Contributor

No description provided.

sumit.jain6 and others added 13 commits August 14, 2026 15:36
- Add IRSA support to eliminate IAM User credentials requirement
- Create dedicated ServiceAccount with eks.amazonaws.com/role-arn annotation
- Update audit CronJob to conditionally use IRSA or legacy credentials
- Enhance db2AuditExtract.sh with --use-irsa flag support
- Add comprehensive IRSA documentation with IAM policy examples
- Maintain backward compatibility with existing IAM User deployments

Benefits:
- No credential rotation required
- Improved ITSS (AWS AccessHub) security score
- Follows AWS security best practices
@amitpandey0217
amitpandey0217 marked this pull request as draft August 24, 2026 08:11
- Separate pods and pods/exec permissions for clarity
- Add conditional secret access only when not using IRSA
- Restrict secret access to specific secret name (resourceNames)
- Remove unnecessary 'list' verb on secrets
- Follows principle of least privilege
Critical architectural fix based on feedback:
- AWS CLI runs INSIDE DB2 pod, not CronJob pod
- CronJob only does 'oc rsh' to exec into DB2 pod
- IRSA must be on DB2 pod's ServiceAccount, not CronJob SA

Changes:
- Created new ServiceAccount for DB2 pod (db2u-{instance_name})
- Added IRSA annotation to DB2 pod ServiceAccount
- Updated Db2uInstance to use IRSA-enabled ServiceAccount
- CronJob SA only needs Kubernetes RBAC (pods/exec)
- Updated documentation with correct architecture diagram

Architecture:
CronJob SA → Kubernetes RBAC → DB2 Pod → IRSA → AWS STS → IAM Role → S3
The CronJob ServiceAccount only needs Kubernetes RBAC to exec into the DB2 pod.
It does NOT need secret access because:
- CronJob pod only runs 'oc rsh' command
- DB2 pod reads secrets directly (legacy mode) or uses IRSA (new mode)
- Secret access was never used by the CronJob pod

Simplified RBAC rules:
- pods: get, list
- pods/exec: create

This follows the principle of least privilege.
Enhanced architecture diagram with:
- Explicit ServiceAccount names
- Clear separation of responsibilities
- OIDC token path details
- S3 policy permissions
- Object Lock mention
- Detailed key points for each component

Makes it crystal clear that:
- CronJob SA: K8s RBAC only, no AWS/secrets
- DB2 Pod SA: IRSA annotation, provides AWS creds
- IAM Role: Temporary credentials via OIDC
- S3: Immutable audit logs with optional Object Lock
The audit script only performs 'aws s3 cp' (upload), so only s3:PutObject is required.

Changes:
- Architecture diagram: Clarified minimal vs optional S3 permissions
- Setup instructions: Added minimal policy (s3:PutObject only)
- Added optional policy with troubleshooting permissions
- Documented that GetObject and ListBucket are optional

Minimal policy (recommended):
- s3:PutObject on audit_logs/* path

Optional (for troubleshooting):
- s3:GetObject (verify uploads)
- s3:ListBucket (list files)

This follows the principle of least privilege.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant