arjun180 commented on issue #1263: URL: https://github.com/apache/camel-kafka-connector/issues/1263#issuecomment-966474648
> Maybe you would need to elaborate a bit more on how exactly you mean it? I asked my colleague @rlonberg to elaborate on the practice of using service accounts instead of the EKS node role. His response is below : The default EKS role (AWS instance metadata) for worker nodes is over-privileged and it's not a good security practice to have pods inherit this node role for a couple reasons.This breaks privilege isolation practices between namespaces. If we give the node role permission to write to an s3 bucket for kafka-connect, now all pods outside of the kafka-connect namespace can access this s3 bucket as well. The EKS default node role needs a few AWS policies to operate that are dangerous for pods to inherit. The EKS node role has the ability to list/describe VPCs subnets and security groups across the entire AWS account. It can describe any EC2 instance in the AWS account (AMIs, private IPs, disks attached). It can nuke all network interfaces in the entire account == this would bring all instances in the account offline and constitute a highly effective denial of service attack vector. It can enumerate and pull any Docker image in the account ECR and also query all image vulnerabilities with ecr:DescribeImageScanFindings in the entire account. It's a better practice to instead assign service accounts to all EKS deployments using least privilege IAM role associations designed specifically for the deployment use-case. Why would a kafka-connect CRD need to do all the above instead of only having the privileges to write to a specific s3 endpoint? This is already the officially accepted practice from AWS: https://docs.aws.amazon.com/eks/latest/userguide/best-practices-security.html#restrict-ec2-credential-access -- who recommend that users restrict access to the instance metadata service when provisioning their EKS cluster and use service accounts instead. Here's another writeup on the problem with using the default node role. It goes into detail on why this practice should be avoided: https://blog.christophetd.fr/privilege-escalation-in-aws-elastic-kubernetes-service-eks-by-compromising-the-instance-role-of-worker-nodes/ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
