Bite-size Otterize: moving fast and (never) breaking things

Move fast and fix things

If you read my last blog post, you'll know that I'm not new at computering™. I'm old enough, and have enough experience, to know that the "move fast and break things" culture just means you end up with broken things. But at least you broke them quickly? No.

What we want is to move fast and fix things! I don't need the stress and anxiety of worrying about breaking a production app. I mean, everyone's broken prod once (or will someday) and no one wants to do it (again or for the first time).

And if I'm going to move fast, the tools I use must make the job much, much easier: they need to give me superpowers. They need to help me tackle big tasks with little effort and little stress. Easy to use. Simple to configure. Safe to deploy. No unintended side-effects.

This is especially true when I'm using a tool to do hard things where mistakes are costly. Have you tried deploying network policies to a large cluster? Or Istio auth policies? Or how about mTLS? None of those things are easy to do nor at all forgiving of mistakes. That's why I want a power tool to do it.

Make it precise

I want to be able to target how I use the tool. Precision. Sure, I want the tool to be easy, and prevent me from making mistakes, but I also don't want to make massive changes all at once. I want to target my usage so I can walk before I run. I want rapid incremental progress that adds value at each step.

And remember, I've been doing this a long time, so I want to be sure that what I'm doing is working. Before it has a chance to blow up on me. Actually seeing what will happen before it happens would be really nice. I'm old enough to remember "trust but verify."

No matter what anyone tells you, sanity is not overrated. So sanity-checking a deployment before it has a chance to go sideways is a good thing. I want to trust my tool, but it has to earn my trust first. So let's do things to sanity-check its abilities.

What am I talking about?

As Head of DevRel here at Otterize, making things right for developers is what I focus on. I make sure that Otterize makes things that are intuitive, easy to use, solve hard problems, and let developers make quick iterations that add value.

When I got here I knew nothing about Otterize, Kubernetes, or securing services within a Kubernetes cluster. In reality, I was the perfect test-subject. And I was eager to ramp up.

As luck would have it, during my onboarding, Otterize was working on some new capabilities to suit precisely those users who wanted more precision in configuring access controls, in driving to zero trust. Users who wanted to deploy Otterize in a more "bite size" way: rapidly, easily, predictably, and incrementally, getting more and more secure at every step.

Making it bite-sized

I was still new to Otterize and the IBAC (intent-based access control) approach when these capabilities became available. The first time I tried them, I was like "YES! THIS is how it's supposed to be!"

And that's because I was able to just pick a single service, any service, that I wanted to protect. I could prepare to protect it by automatically ensuring all clients that should be able to reach it would be able to, in one step, and then actually protect it, in a second step. Without impacting anything else! The protection is done by configuring network policies, which are built into Kubernetes itself. But I didn't have to touch network policies themselves, much less be an expert with them.

In fact, step 1, knowing which clients intend to call the service is one of those superpowers I mentioned. The Otterize open source network mapper finds the clients calling services in your cluster. If you believe those calls are likely the way the code is supposed to behave, you can export those call patterns as client intents. And you can export just the clients of a single server:

% otterize network-mapper export --server frontend.otterize-ecom-demo -o clients.yaml

All you need to do to declare that these are the authorized clients is run kubectl apply -f clients.yaml, and Otterize will ensure they'll have access to the frontend.otterize-ecom-demo service when you protect it.

The Otterize Cloud access graph UI will even show you, visually, that these authorized clients will be able to call that service once protected. Think of it as a dry run for what will happen when you protect.

Then protecting it, step 2, is just as easy. Create this short protect-frontend.yaml file and kubectl apply it too:

apiVersion: k8s.otterize.com/v1alpha2
kind: ProtectedService
metadata:
  name: frontend
  namespace: otterize-ecom-demo
spec:
  name: frontend

And really that's all it takes! Quick. Easy. High precision. It just works. Otterize labeled pods, labeled namespaces, and created and applied network policies to a single service without affecting anything else and without me having to fuss over anything.

So then I thought "Let me just work my way across my access graph here and protect another service, and then another ..."

Watch as I move across the access graph and protect everything, one service at a time.


Doing all of that took 8 more commands: 2 to create all the intents, and then 6 more to protect each service. Most important for someone as careful as me: I didn't have to do it all at once.

It does what I want

I now have a tool that easily and effortlessly does exactly what I want -

and I generally dislike the use of the word "easy" because, well, just because something's easy for me doesn't mean it will be easy for you.

At this point I'll refer you back to the previous section when I told you I knew less than nothing about deploying network policies in a Kubernetes cluster. Guess what? I still don't know how to do it. At least not the old-fashioned way. But I just did it. I did it slowly, service-by-service, and I didn't break anything in the process. I ended up with all of my services protected. And it wasn't a 6-month project. It took 5 minutes.

That's it!

No, really, that's it! It's a joy to work with. I can apply intents and protection and see it in my Otterize Cloud access graph in real time so I know what's happening the whole time. I can grow my level of confidence as I progress — and I can complete it without breaking anything. HUZZAH!!

Ready to experience this game-changer for yourself?

Take our new Otterize tutorial out for a spin and join our Slack Community to let us know what you think!