Long-term cloud credentials are oftentimes (intentionally or accidentally) littered in source code, laptops/desktops, servers, cloud resources, etc. It’s easy for credentials to be copied across machines, creating sprawl that is at best, difficult to manage and at worst, unnecessarily increasing leakage risk. Furthermore, these types of credentials are only necessary when non-cloud infrastructure resources need to communicate with cloud resources; for example, data center servers trying to use AWS S3 bucket. Generally speaking, there is no good reason to have long term credentials anywhere else—employees should instead use temporary credentials by authenticating with the SSO service.
AWS Elastic Container Service (ECS) and Elastic Kubernetes Service (EKS) require provisioning of compute resources to run container workloads.
Organizations should transition EC2 instances to use Instance Metadata Service Version 2 (IMDSv2) because IMDSv1 is susceptible to server-side request forgery (SSRF) attacks. Uptycs customers should be cautious about enabling the curl table in osquery. Uptycs has updated our version of osquery to work with IMDSv2, and we’ve implemented a rule to help customers identify EC2 instances using the vulnerable metadata service.
Kubernetes nodes – the machines responsible for running your container workloads – can come in a number of shapes, sizes, and configurations. One common deployment pattern, however, is a lack of in-transit encryption between them.
Another common deployment pattern? Lack of TLS support on the container workloads themselves. After all, who wants to set up and manage a PKI (Public-Key Infrastructure) and a private CA (Certificate Authority) for tens or hundreds of microservices, and get the certificates to be trusted by all workloads? I don’t know about you, but that doesn’t sound like a lot of fun to me.