This technical deep dive highlights key capabilities released as part of Twistlock 18.11. To learn more about what’s included with Twistlock 18.11, check out our full release blog post.
Twistlock is designed to protect your cloud native environment regardless of where you choose to build and run your applications. Anywhere you’d want protection, you can get protection. But, what if you don’t know about all the cloud native services running at your organization that you should be protecting with Twistlock? This question is a common concern that has come up again and again when I’d speak to our users.
The growing number of cloud native services in use
Organizations we work with grow their cloud native services over time. They start with perhaps one cloud provider account and before they know it they have multiple business units with their own accounts or even multiple teams with accounts. Usually the only controls are focused on spend and ensuring that someone has control over the root admin account.
The eagle-eyed amongst you will have noticed that we made an open source contribution recently called Twistlock Cloud Discovery. This announcements follows a long line of giving back to the community, authz, the secrets plugin for Docker Swarm, and NIST SP 800-190, to name a few. You can learn more about Cloud Discovery here in our blog announcement.
In our most recent release, we’ve taken that open source contribution and integrated it into the Twistlock Platform. Now, you have that same single pane of glass that you’ve always had with Twistlock, but now visibility into any services that spring up in these accounts which Twistlock is not protecting.
Now Twistlock does know about what cloud native services are being used at your organization even if you don’t!
Best of all… then you can protect them! The appropriate protection in Twistlock is created ready for you to adjust if needed.
What’s it look like? A deep dive on AWS
First, let’s first plug in some AWS credentials into our credential management area, another new feature from Twistlock 18.11. You can see this view in the screenshot below:
Grand, that’s the credentials setup. I’m looking at AWS and using an access key pair. I could equally have used an API token or basic auth and pointed at Azure or GCP.
Next, let’s tell Twistlock to scan my organization to see what cloud native services are being used by navigating to Defend > Compliance > Cloud Platforms.
I add a quick check box next to my AWS credentials to activate the feature and away we go!
Then, I navigate to Monitor > Compliance > Cloud Platforms to see what is being used at my organization….and what do we have here?
In the above screenshot, we can see that there are a number of services that Twistlock is not yet protecting! Let’s deal with that top entry, a registry that I would like to monitor for vulnerabilities and compliance issues. If I click on the ‘“protect” icon on the right, I’m immediately taken to add that as a registry to scan with Twistlock.
As you’d expect, this ties into our existing logging and alerting — just another of those awesome features that gets built and provided to our customers. Well done, Twistlock.
With Cloud Platform Compliance, you can identify protected and unprotected services and deploy Twistlock to protect any unprotected environments. You can have your internal and external registries scanned as well as scan your underlying hosts, images and containers and protect them at runtime. Now even your cloud (or multiple clouds!) can be scanned and secured all through your one deployment. You can even do all of this making use of multiple deployments managed through a single Console, which I highlighted several releases ago.
If you’d like more information or want a demo then get in touch!
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
Five Best Practices for API SecurityRead the Blog
When On-Premise Serverless Beats the CloudRead the Blog
Kubernetes AuditSink: Real-time K8s Audits and ForensicsRead the Blog
Native Helm Charts for Frictionless Kubernetes DeploymentsRead the Blog
How Knative Can Unite Kubernetes and ServerlessRead the Blog