AWS Config vs Kubernetes Native Policy Engines: Who Governs What?

In modern cloud-native environments, compliance, governance, and standardization are critical to ensuring security, operational efficiency, and regulatory adherence. As organizations adopt containerized infrastructure, enforcing consistent policies across platforms like Amazon EKS (Kubernetes-based) and ECS (serverless containers) becomes increasingly complex.

At first glance, AWS Config and Kubernetes-native policy engines like OPA Gatekeeper and Kyverno may appear to serve the same function — enforcing rules and ensuring compliance in containerized workloads. But in reality, they operate at different layers, solve distinct problems, and target different scopes of governance. AWS Config is designed for cloud-wide compliance across AWS resources, whereas Kubernetes-native engines are focused on cluster-level policy enforcement within the Kubernetes API lifecycle.

In environments where workloads span EKS, ECS, and other AWS services, these tools must often coexist — not compete. This article dives into their differences, where they overlap, and most importantly: who really governs what in a dynamic, multi-platform cloud environment.

What is AWS Config?

AWS Config is a service that continuously monitors and records AWS resource configurations and evaluates them against desired states. Think of it as a compliance engine: it tracks configuration changes and helps you answer questions like:
- Are my EKS clusters configured securely?
- Are ECS tasks using only approved IAM roles?
- Is anything exposed to the public internet unintentionally?

In a cloud environment, AWS Config works by recording and capturing configuration changes in AWS resources using a Config Recorder. By applying AWS Config rules (either managed or custom lambda rules), it can automatically assess whether your resource configurations adhere to best practices and compliance standards. Finally, when noncompliant configurations are detected, AWS Config can initiate automatic remediation actions (if configured) using AWS Systems Manager Automation documents, ensuring resources are promptly corrected to maintain compliance.

Using AWS Config with EKS and ECS

When operating Kubernetes or container workloads at scale, governance isn’t optional — it’s essential.

In Amazon EKS, AWS Config helps you track key components such as: EKS control plane logging, VPC settings and network exposure, encryption status for logs and secrets and IAM roles used by worker node groups. It can detect misconfigurations like:
🚫 Publicly accessible EKS clusters
⚠️ Disabled encryption for secrets stored in Kubernetes ETCD
⚠️ Ensures EKS clusters are running on currently supported versions,

In Amazon ECS, AWS Config can monitor task definitions, IAM roles attached to ECS tasks, changes to security groups and public IP assignments. It can enforce controls like:
✅ Ensuring tasks use only approved IAM roles
✅ Ensures Container Insights are enabled on ECS clusters for observability
🚫 Verifies containers do not run with privileged access

AWS Config Rules and Conformance Packs

AWS Config setup is incomplete without Config rules. Config rules are logic-based checks that evaluate whether your AWS resources comply with defined configurations. There are two types: Managed Rules (prebuilt by AWS to address common compliance needs) and Custom Rules (built using AWS Lambda functions). Each rule evaluates compliance in response to configuration changes or periodically, giving you real-time insight into your environment's configuration drift.

Example Rules:

• ec2-instance-no-public-ip: Flags any instance launched with a public IP
• ec2-ebs-encryption-by-default: Checks if Amazon Elastic Block Store (EBS) encryption is enabled by default.
• restricted-ssh: Checks whether security groups that are in use disallow unrestricted incoming SSH traffic

Rather than managing individual rules across multiple accounts, Conformance Packs let you bundle together Config rules as a collection, making it easier to be applied in multiple accounts - think of it as policy-as-code for cloud governance. AWS provides many prebuilt packs for EKS best practices, CIS Benchmarks, PCI-DSS, HIPAA, NIST compliance and general security hardening. You can find them on GitHub. You can also customize your own packs, combining both managed and custom rules.

Conformance Packs Dashboard

Rules Under Conformance Pack

Kubernetes Native Policy Engines: Kyverno and OPA Gatekeeper

Kubernetes Native Policy Engines are tools that integrate directly with the Kubernetes API to enforce governance, security, and compliance rules using policies defined as code. They work by integrating with the Kubernetes admission control process, allowing it to inspect, validate, mutate, or reject resource requests before they are applied to the cluster. They allow cluster administrators to define and enforce standards across workloads and infrastructure in a Kubernetes-native way.

Here’s how it works in a simplified flow:

The most common Kubernetes native policy engines are Kyverno and OPA Gatekeeper.

Kyverno is a Kubernetes-native, declarative policy engine designed specifically for Kubernetes. It enables writing policies using YAML, making it accessible to users without needing a new language. Kyverno supports resource validation, mutation, and generation, aligning well with Kubernetes patterns.

OPA Gatekeeper is a powerful policy engine that uses the Rego language to define complex policies. Gatekeeper extends OPA to Kubernetes, offering admission control and audit capabilities for enforcing custom rules with broader control over Kubernetes objects.

Use cases of Kubernetes policy engine in EKS include:

• Pod Security Policies: Restrict privilege escalation, enforce runAsNonRoot, and control host networking.
• Network Segmentation: Enforce network policies to control communication between pods or namespaces.
• RBAC Rules Enforcement: Prevent creation of overly permissive roles or bindings.
• Namespace Restrictions: Limit what resources can be created or configured in specific namespaces.

#Kyverno policy enforcing resource limits in specific namespaces

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-resource-limits
spec:
  validationFailureAction: enforce
  background: true
  rules:
    - name: validate-resources
      match:
        resources:
          kinds:
            - Pod
      preconditions:
        all:
          - key: "{{request.object.metadata.namespace}}"
            operator: In
            value: ["default", "production", "staging"]
      validate:
        message: "Resource limits are required for CPU and memory"
        pattern:
          spec:
            containers:
              - resources:
                  limits:
                    memory: "?*"
                    cpu: "?*"
                  requests:
                    memory: "?*"
                    cpu: "?*"

AWS Config vs Kyverno/OPA: The Governance Divide

When to Use What? (AWS Config vs Kyverno/OPA)

Use AWS Config for infrastructure-level governance and enforcing compliance across AWS services. For example, ensuring your EKS cluster is private and secure. Use Kyverno or OPA for runtime policies and workload-level enforcement inside Kubernetes, like allowing only signed container images to run. They complement each other and are best used together to ensure both infrastructure and workloads stay compliant and secure.

Conclusion

Cloud-native governance is multi-layered — no single tool covers it all. AWS Config provides cloud-wide compliance across AWS services, while Kubernetes-native policy engines like Kyverno and OPA Gatekeeper enforce fine-grained rules within clusters. These tools are complementary, not competing. Together, they enable both infrastructure-level and workload-level governance.

Ultimately, this calls for a DevSecOps mindset — one that combines shift-left enforcement with continuous monitoring, ensuring security and compliance at every stage of the delivery pipeline.

References:

• https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html
• https://docs.aws.amazon.com/config/latest/developerguide/setup-autoremediation.html
• https://docs.aws.amazon.com/toolkit-for-vscode/latest/userguide/systems-manager-automation-docs.html
• https://github.com/awslabs/aws-config-rules/tree/master/aws-config-conformance-packs
• https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#admission-control-phases
• https://kyverno.io/docs/
• https://github.com/open-policy-agent/gatekeeper