How Cloud-Native Zero-Trust Could Up its Game With Permissions

Let’s chat about something that might sound a bit technical but actually affects our digital lives more than we realize: Permissions. Specifically, we’ll explore what cloud-native zero-trust access control could learn from how Android and iOS handle permissions. This is especially important for cloud-native applications built using microservices and containers and running on platform like Kubernetes.

So, here’s the deal with iOS and Android permissions—they’re all about you, the user. These permissions are designed to be straightforward. When you download an app, it tells you exactly what resources it needs to access. For example, if a weather app wants to know your location, it just asks for permission to access location services. Once you say “yes,” it can use all the related features hassle-free.

Now, let’s shift gears to the cloud-native world. It’s a bit of a different story here. Instead of simple declarations, we’re dealing with complex policies and permissions. Developers often don’t set these permissions on the user’s device; instead, they configure them on the server side. You might know what a service will do or what resources it’ll use, but you might not know exactly which permissions are involved.

For instance, think about AWS CloudTrail. If you want it to work, you need to set up AWS S3 permissions separately. It’s not as straightforward as granting access, like in mobile apps.

The big difference is that mobile app permissions are self-contained, whereas in cloud-native setups, access controls are tightly connected to the server. So, if something changes on the client side, it’s usually the server’s policy that needs adjusting. This can create coordination issues between client and server teams.

Now, back to mobile permissions. You don’t have to dive into your phone’s settings and tweak the global rules for each app to function properly. The app states its needs in its manifest and the operating system takes care of the rest. It’s a simple and organized way of doing things.

The cloud-native world could learn a thing or two from this simplicity. Imagine if services in the cloud could declare their access requirements, and the system would automatically compute the overall policy. If there were technical reasons to keep it server-side, that’s not the developer’s problem; it’s the system’s job to handle it.

So, here are some lessons that cloud-native computing can borrow from mobile app permissions:

• Version and deploy access controls alongside the client: This makes it easier to manage and update access requirements.
• Use declarative controls: Focus on what resources a service needs rather than individual permissions.
• Allow static analysis: Make it possible to determine if a service can function successfully just by looking at the declaration without worrying about runtime details.
• Ownership: Keep access control in the hands of one person or team to simplify the process.

Imagine if we could have an access control system that’s truly declarative and produces policies automatically. You’d just declare your service’s required access, and the system would handle the rest. No more diving into a sea of resources and policies to figure things out.

This idea might sound abstract, but it’s been floating around under various names. The most fitting one, in my opinion, is “intent-based access control,” or IBAC. You declare your intentions and the system ensures that access is granted with the least privilege and zero-trust without depending on other declarations.

As a platform engineer, this concept is like a breath of fresh air. No more headaches trying to decipher complicated access rules—it’s simply crazy good! Finally, we can have a system that just works.

To hear more about cloud-native topics, join the Cloud Native Computing Foundation and the cloud-native community at KubeCon+CloudNativeCon North America 2023 – November 6-9, 2023.