About This Architecture

Cross-account Route53 Resolver Query Logging Controller running on EKS with Pod Identity and STS AssumeRole for secure DNS query capture across multiple AWS accounts. The controller reconciles ResolverQueryLogConfig and IAMRoleSelector CRDs, assuming per-account execution roles to provision query log configurations and associations to workload VPCs. Query logs stream to CloudWatch Log Groups in each client account, enabling centralized DNS observability while maintaining least-privilege cross-account access. Fork this diagram to customize role trust policies, add Kinesis destinations for SIEM integration, or adapt the controller pattern for multi-region deployments. This architecture demonstrates Kubernetes-native infrastructure-as-code for AWS service management at scale.

People also ask

How do you implement a Kubernetes-native Route53 Resolver Query Logging Controller that securely logs DNS queries across multiple AWS accounts using Pod Identity and STS AssumeRole?

This diagram shows an EKS-based controller that uses Pod Identity to bind a ServiceAccount to Role A (sts:AssumeRole only), which assumes per-account execution roles (Role B) via STS to provision Route53 Resolver Query Log Configs and associations in client workload VPCs. Query logs are streamed to CloudWatch Log Groups in each account, enabling multi-account DNS observability with least-privilege