In the evolving landscape of cloud-native technologies, security remains a paramount concern, especially for applications deployed on Kubernetes clusters like Amazon EKS. As we dive into the eighth installment of our series, we focus on implementing a multi-layered security strategy leveraging AWS IAM, Kubernetes Network Policies, and Istio’s security capabilities. This approach ensures our microservices architecture is not only scalable and efficient but also secure against potential threats.

Securing Kubernetes Cluster

AWS IAM for Kubernetes Authentication

AWS Identity and Access Management (IAM) plays a crucial role in controlling access to your AWS resources, including EKS. To integrate AWS IAM with Kubernetes for authentication:

  1. Map IAM Users and Roles to Kubernetes RBAC: Use the AWS IAM Authenticator for Kubernetes to map IAM users and roles to Kubernetes Roles or ClusterRoles, thus leveraging AWS’s robust identity services for cluster access control.
apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: arn:aws:iam::<AWS_ACCOUNT_ID>:role/<EKS_NODE_ROLE>
      username: system:node:
      groups:
        - system:bootstrappers
        - system:nodes

Replace <AWS_ACCOUNT_ID> and <EKS_NODE_ROLE> with your specific AWS account ID and the IAM role associated with your EKS nodes.

Kubernetes Network Policies for Pod-level Security

Kubernetes Network Policies specify how pods communicate with each other and the outside world. They are essential for creating a secure microservices environment:

  1. Default Deny All Ingress and Egress: Start with a default deny-all policy and then allow specific traffic as needed.
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: default-deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  1. Allow Specific Ingress/Egress: Define policies that allow necessary traffic based on labels, ports, and other criteria.
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-http
spec:
  podSelector:
    matchLabels:
      app: my-app
  policyTypes:
  - Ingress
  ingress:
  - from: []
    ports:
    - protocol: TCP
      port: 80

Enhancing Security with Istio

Istio extends Kubernetes security features with capabilities like mutual TLS (mTLS) for service-to-service encryption, fine-grained access control, and more.

Enabling Mutual TLS in Istio

  1. Global mTLS Configuration: You can enable mTLS globally for all services in the mesh through Istio’s PeerAuthentication policies.
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT
  1. Namespace-level mTLS Configuration: Alternatively, enable mTLS for a specific namespace to incrementally adopt mTLS.
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: <YOUR_NAMESPACE>
spec:
  mtls:
    mode: STRICT

Replace <YOUR_NAMESPACE> with the target namespace where you want to enforce mTLS.

Istio Authorization Policies for Fine-grained Access Control

Define Istio Authorization Policies to control access to services based on identities, namespaces, and labels.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-http-get
  namespace: <YOUR_NAMESPACE>
spec:
  selector:
    matchLabels:
      app: my-app
  action: ALLOW
  rules:
  - to:
    - operation:
        methods: ["GET"]

Conclusion

Adopting these security best practices for Kubernetes and Istio within the EKS environment establishes a robust security posture for your microservices architecture. By leveraging AWS IAM for authentication, enforcing network policies for pod communication, and utilizing Istio’s security features, we can ensure our applications are secure from the ground up.

Gotchas and Tips

  • Regularly Audit IAM Policies: Ensure IAM roles and policies are regularly reviewed and updated to adhere to the principle of least privilege.
  • Monitor Network Policies: Keep track of your network policies to ensure they don’t inadvertently block necessary traffic or expose sensitive services.
  • Test Security Configurations: Regularly test your security configurations, including mTLS and authorization policies, to ensure they behave as expected without introducing service disruptions.

Security in a cloud-native environment is an ongoing process. By continuously

applying and updating these best practices, you can safeguard your cluster against emerging threats while maintaining a secure, performant, and reliable infrastructure.