Cloud Native Meetup Linz #2

[Introduction]

Hi, everyone. Thanks for having me. My name is Damjan, and I’m the Head of Technology at Posedio. We’re a relatively young company, founded about three to four years ago, primarily focusing on cloud-native development. You may have seen us around, and I’ve noticed some KCD Austria shirts here, so maybe you caught us at the last event. We specialize in software engineering, infrastructure setup, and DevOps—the full range of services within the cloud-native space.

I started my career as a software engineer. I studied at TVIN and moved to Vienna in 2012, originally coming from Macedonia. My journey began with Java backend development, then transitioned into full-stack development with React and TypeScript. Over time, I moved into DevOps, platform engineering, Kubernetes, and Google Cloud. Currently, my main focus is on building a data platform, working at the intersection of platform and data engineering.

I’ve worked on several large-scale projects in the cloud-native space. One of them involves one of Austria’s largest transaction processing services. If you’re curious about the details, feel free to ask me later—just not on record. Another major project I worked on was an internal developer platform for the same company. Throughout this process, I’ve developed a strong interest in security, particularly how security in the cloud-native space differs significantly from traditional security models.

[Security in the Cloud-Native Space]

Security in cloud-native environments is fundamentally different from traditional perimeter-based security models. Older security approaches focused on network perimeter security—putting up firewalls and assuming everything inside the private network was safe. However, with modern microservices architectures, this approach is no longer sufficient.

Today, services are constantly changing, and their locations and identities are dynamic. The traditional model of segmenting networks into public, DMZ, and private zones does not provide adequate security in cloud-native environments. Firewalls and network segmentation still have value, but they should not be the only security measure relied upon.

This brings us to the concept of Zero Trust security, which follows the principle of “trust but verify.” Instead of assuming that anything inside the perimeter is safe, every request must be authenticated and authorized, regardless of its origin. This ensures security at every level, not just at the network boundary.

[Key Security Concepts]

To establish a shared understanding, let’s define some key security terms:

• Confidentiality: Ensuring that sensitive data is only accessible to authorized users.
• Integrity: Preventing unauthorized modification of data.
• Availability: Ensuring that systems and data remain accessible to authorized users when needed.

To achieve these security goals, we use the AAA model:

1. Authentication – Verifying the identity of users and machines.
2. Authorization – Determining what authenticated entities are allowed to do.
3. Auditing – Keeping track of security events and ensuring accountability.

A crucial lesson I’ve learned is that authentication and authorization are distinct processes. For example, we once assumed that a Google service handled both authentication and authorization for us. However, we later realized that while Google confirmed the identity of users, it did not enforce any authorization policies. This highlights the importance of implementing authorization separately and not assuming authentication providers handle it.

[Establishing Trust]

Security always relies on some form of trust. However, the challenge is determining what can be trusted. Every system needs a root of trust, whether it’s a trusted identity provider, hardware, or cryptographic mechanism. The problem is that trust decisions always involve some level of risk acceptance. There’s an insightful paper from the 70s that illustrates how, in theory, you can never fully trust any software, as everything ultimately depends on the trustworthiness of compilers, hardware, and lower-level systems. That said, we must do our best to mitigate risks, as the alternative—doing nothing—is far worse.

[Human vs. Machine Identities]

Security considerations differ depending on whether we’re dealing with human identities, machine identities, or workload identities:

• Human Identities: Employees, customers, and external users who authenticate via traditional methods (e.g., usernames, passwords, MFA).
• Machine Identities: Servers, jobs, or services that authenticate via service accounts, certificates, or API keys.
• Workload Identities: Cloud-native workloads that dynamically authenticate with short-lived credentials.

Traditionally, network security relied on IP-based identity verification. However, in cloud environments where workloads frequently move, IP addresses are no longer a reliable identity mechanism. Instead, we rely on workload identity solutions that authenticate services dynamically.

[Security Tools and Best Practices]

There are several open-source tools that help implement strong security in cloud-native environments:

• Open Policy Agent (OPA): A policy engine that allows centralized enforcement of authorization rules.
• SpiceDB: Based on Google Zanzibar, this authorization system models relationships between entities in a scalable way.
• Vault (or OpenBao): A secrets management tool that dynamically generates credentials and encrypts sensitive data.
• Istio (Service Mesh): Implements mTLS for secure service-to-service communication.
• Cosign: Ensures container image integrity by verifying cryptographic signatures.
• Falco: Provides real-time security threat detection for Kubernetes clusters.

[Real-World Implementations]

We’ve successfully implemented these security practices in several projects. One example is a multi-tenant financial services platform. Each tenant is completely isolated using Vault, Keycloak, and Kubernetes workload identities. The backend dynamically retrieves database credentials from Vault, ensuring that no credentials are statically stored or shared between tenants.

Another example is an internal developer platform for a large enterprise. Developers deploy workloads to Kubernetes namespaces assigned to their teams. Authentication is managed through Keycloak, and workload identities are used to grant permissions dynamically. To enforce security policies, we use Istio for network segmentation and Vault for secrets management. Additionally, we have automated image scanning and signing to ensure secure deployments.

[Challenges and Lessons Learned]

Maintaining security in cloud-native environments is an ongoing challenge. One of the biggest lessons we’ve learned is the importance of automating security updates. We use tools like Renovate to automatically update dependencies and apply security patches. However, even with automation, human oversight is necessary to ensure that updates do not introduce breaking changes.

Another challenge is balancing security with usability. For example, developers often request access to production environments for debugging. We implemented a privileged access management system where developers must explicitly request access and justify their need, ensuring accountability while maintaining security.

[Conclusion]

Security in cloud-native environments is complex, but by leveraging the right tools and adopting a Zero Trust approach, we can build systems that are both secure and scalable. If you have any questions or want to discuss any of these topics further, feel free to reach out. Thanks for your time!

[Applause]

Schreibe etwas…