Uptycs Blog

Welcome! The Uptycs blog is for security professionals and osquery enthusiasts interested in exploring new ideas in cloud security. We hope you’ll enjoy our blog enough to subscribe and share.

Where secrets lie: Reduce credential leakage risk by inventorying AWS access keys

Where secrets lie: Reduce credential leakage risk by inventorying AWS access keys

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. 

Use Uptycs and osquery to secure your AWS Fargate containers on ECS

Use Uptycs and osquery to secure your AWS Fargate containers on ECS

AWS Elastic Container Service (ECS) and Elastic Kubernetes Service (EKS) require provisioning of compute resources to run container workloads.

You should be using AWS IMDSv2: Here’s why and how to do it

You should be using AWS IMDSv2: Here’s why and how to do it

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.

Harnessing the AWS Nitro Architecture to Encrypt Inter-Node Traffic in Kubernetes

Harnessing the AWS Nitro Architecture to Encrypt Inter-Node Traffic in Kubernetes

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.