New year, new features

Dear otter fans, customers, and pets who have been enjoying nibbling on an Otterize plushie,

We have some exciting announcements for the new year! New features for both security and platform teams, usability improvements, performance improvements, and more!

The short version for busy otters

• ClientIntents v2: usability improvements to ClientIntents, making them easier to understand also generate more restrictive policies by default. Read more on the docs >>

• Access graph usability and performance improvements for very large graphs: grouping by namespace and cluster, improved workload/flow menu, and performance improvements for very large graphs.

• Support for runtime data classification, DSPM and fully automated PCI compliance

• Linkerd support: a community contribution from @aerosouund!! Read more on the docs >>

• AWS IAM visibility: now using eBPF: Try it out in the tutorial >>

• Azure IAM visibility: Try it out in the tutorial >>

• AWS discovery: See AWS EKS clusters in the access graph even when Otterize is not installed on them yet

• Wildcard Internet intents

• Export ClientIntents from Cloud using CLI

• AWS marketplace availability

Keep reading for the details!

Want to learn more about these updates or see a demo? Book a meeting with an engineer!

About Otterize

Otterize’s Microsegmentation and Least-privilege for Kubernetes Workloads platform is a best-of-breed solution for Kubernetes Non-Human Identity Access, combining AI-based data classification with eBPF-based visibility and platform-native enforcement, for anything from network security, to databases, and even cloud resources like S3 buckets.

The detailed version for those who need to know all the deets

ClientIntents v2

We have revamped the format for ClientIntents to make them easier to understand and make it possible to generate more restrictive policies by default. Read more on the docs >>

The two primary changes:

1. service is no longer used, except to mean a Kubernetes Service; before, it could mean an Otterize Service or a Kubernetes Service, which was confusing. Instead, we now use workload.

2. calls has also been renamed targets, and many smaller changes were made to the structure to simplify and make it easier to understand.

What happens to your existing ClientIntents? Don’t worry, the change is backwards compatible, and nothing changes unless you explicitly upgrade.

If you’re a customer, we’ll reach out to explain and plan together.

If you’re using the open source, upgrading to the next major version of the otterize-kubernetes Helm chart, v5.0.0, will make ClientIntents v2 the default.

You can still continue using ClientIntents with apiVersion v1alpha3, even after v2 is the default.

Access graph

The access graph now groups workloads by namespace and cluster.

• These groups can be collapsed one at a time, with one click for each cluster, or for all clusters at once. The controls can be found on the icon on top of each cluster, or global controls in the top right.

• This makes huge graphs much easier to navigate, and makes it easier to focus on what matters most.

Improved workload/flow menu

• The access graph menu that appears on the right hand side when you click a workload or flow has been redesigned, and now surfaces important information in summaries.

• New: Events section will show you the Kubernetes Events on a ClientIntents resource from the cluster. This allows you to see any error or warning messages when troubleshooting.

Performance improvements

• There should be a noticeable improvement both to loading times and browser rendering performance for very large graphs.

• We have increased the maximum zoom out so that you can see your entire infrastructure at once.

Support for runtime data classification, DSPM and fully automated PCI compliance

Otterize can now use eBPF to inspect both SSL and non-SSL encrypted data and automatically tag it with PII and PCI tags, and scope PCI automatically using that information.

Enable it with

--set networkMapper.nodeagent.enable=true

This goes hand-in-hand with the Cloud Security Compliance features. If you need PCI compliance, enable this feature as well as the set of PCI controls on the Cloud Security > Controls page, and Otterize will generate findings for non-compliant workloads according to PCI DSS v4.

Linkerd support

Otterize now supports Linkerd, a community contribution from @aerosouund!! Read more on the docs >>

Specify ClientIntents to a Kubernetes workload and Otterize will label pods, generate Server, MeshTLSAuthentication, HTTPRoute and AuthorizationPolicy resources to secure the access. You can also specify the HTTP field to restrict access at the Layer 7 Path/Method level.

AWS IAM visibility: now using eBPF

The AWS IAM visibility feature now uses eBPF instead of a proxy, and currently supports Python, node.js and Golang.

Otterize can now autogenerate ClientIntents for AWS IAM with a simple, zero-config deployment. Try it out in the tutorial >> or just enable the eBPF node agent with

--set networkMapper.nodeagent.enable=true

Azure IAM visibility

Otterize can now autogenerate ClientIntents for Azure IAM with the same simple, zero-config deployment, for Python, node.js and Golang. Try it out in the tutorial >> or just enable the eBPF node agent with

--set networkMapper.nodeagent.enable=true

AWS discovery: Detect AWS EKS clusters

Otterize is now able to detect AWS EKS clusters your workloads are communicating with, but on which Otterize is not installed, and find them in your AWS account, making them appear as an EKS cluster in the access graph rather than unknown Internet traffic.

This is designed to help security and platform teams discover clusters on which Otterize is not yet installed, to gain visibility into cross-cluster communication.

To enable this feature, either click the button in your access graph when you see an AWS discovery prompt, or head to the Integrations page to install the AWS Discovery integration.

Wildcard Internet Intents

You can now specify wildcard domains in Internet intents, and Otterize will track DNS requests from pods in the cluster to allow only intended access. Try the egress network policy tutorial >>

Export ClientIntents from Cloud using CLI

You can now export ClientIntents from the Cloud using the CLI. For example:

otterize clientintents export -c Production -n otterize-tutorial-iam.Production

exports ClientIntents from the namespace otterize-tutorial-iam in the cluster named Production.

Previously, otterize mapper export would require you to be connected to the relevant cluster and would only export network-level intents. Exporting from the Cloud allows you to also export IAM and Internet intents, and is easier to use from CICD and your laptop since it does not require a connection to the cluster.

AWS marketplace

We are now on the AWS marketplace! If you’re a customer and want to switch to paying through the AWS marketplace, do tell us.