Shepherding your Cloud Native “cattle” with Tornjak
In the cloud native world, there is a saying that we treat our workloads and services like “cattle, not pets”. This stems from the idea that we are moving from fewer long-lived workloads to a microservices architecture where we have many short-lived workloads. This shift in mentality brings with it a change in how operators and administrators manage their workloads.
In a cloud native microservices architecture, the number of workloads in an organization are not only vast in quantity, but the workloads’ underlying computation is often ephemeral and spans across multiple platforms and services (e.g. cloud, serverless, functions, etc.). This makes managing workloads more difficult in the new paradigm.
Putting it in context of the “cattle, not pets” analogy, administrators and operators need to be able to shepherd workloads and services within their organization, ensuring that there is visibility, management, auditability and compliance of workloads. This is exactly what the new “Tornjak” project does with the SPIFFE/SPIRE by allowing administrators, operators, and CISOs to better manage their workload identities across their deployments.
Background: SPIFFE/SPIRE
Tornjak project is based heavily on SPIFFE/SPIRE. If you are unfamiliar with what SPIFFE/SPIRE are, here’s a quick summary, but if you’d like to dive deeper, check out the SPIFFE/SPIRE book: “Solving the Bottom Turtle: A SPIFFE way to establish Trust in Your Infrastructure via Universal Identity”
- SPIFFE, the Secure Production Identity Framework For Everyone, provides a secure identity, in the form of a specially crafted X.509 certificate, to every workload in a modern production environment. SPIFFE removes the need for application-level authentication and complex network-level ACL configuration.
- SPIRE, the SPIFFE Runtime Environment, is an extensible system that implements the principles embodied in the SPIFFE standards. SPIRE manages platform and workload attestation, provides an API for controlling attestation policies, and coordinates certificate issuance and rotation.
What is Tornjak?
Fun Fact: The name Tornjak (pronounced “tornyak”) originates from the Tornjak mountain sheep dog breed native to Bosnia and Herzegovina and Croatia. The breed is commonly used for sheepherding, which is why the name “Tornjak” fits with how we are trying to help herd our cloud native “cattle”.
The Tornjak open source project aims to provide a management plane and capabilities for SPIFFE identities managed by SPIRE. The goals are to provide global visibility, auditability, configuration and policy management for workload identities. Utilizing CNCF standard/implementation SPIFFE/SPIRE, Tornjak provides a management plane on top of the secure SPIRE framework that helps provide a Zero Trust security model. This management plane can be used by an administrator or CISO to govern an organization’s workload identities.
A simple k8s scenario of SPIFFE/SPIRE + Tornjak (quickstart)
In this section, we will go through a demo of how to configure Tornjak as well as some of the basic features of Tornjak such as the Tornjak SPIRE Server UI, as well as the additional APIs to help provide additional SPIRE server information and annotating additional metadata for SPIRE agents. Tornjak is able to manage multiple SPIRE servers as well, but for this post, we will be keeping it simple with just a SPIRE deployment on a single kubernetes cluster.
Let’s dive in!
Let’s start digging into how we can use Tornjak with a very simple example. The scenario here is based directly on the SPIFFE/SPIRE quickstart guide for Kubernetes, where we have a single kubernetes cluster installation with all the SPIRE components. The steps of how to run this document yourself can be seen in this tutorial. This is a video of the steps carried out in the tutorial.
NOTE for existing SPIRE users: Basic use of Tornjak can be integrated very simply without much configuration. If you have a SPIRE server running using the SPIRE server image, e.g. gcr.io/spiffe-io/spire-server:0.12.0, you can enable Tornjak by replacing the image with the tornjak image: tsidentity/tornjak-spire-server:0.12.0, ensuring the the version tag is preserved (supported versions today are 0.11.0 to 0.12.1). Doing this will run the SPIRE server as usual with an additional server running HTTP on port 10000 that serves the Tornjak UI.
Next, we can see some of the basic functionality and use-cases of Tornjak today, including global visibility, assisted entry creation, ability to add on metadata to SPIRE entities, and a dashboard to navigate one’s SPIRE architecture.
Some other scenarios
In this section, we will explore several other uses and scenarios to give a better idea on what can be done, we will then dive into some of the upcoming features in Tornjak!
Multi SPIRE Server deployment
If we have a deployment where we have multiple SPIRE servers, and multiple trust domains, Tornjak has a manager which can be used to manage multiple servers in a simple location. The same functions (and more) are available on the Tornjak manager.
This way a CISO or operator is able to manage workload identity across the organization in one place. After all, we manage our user identities in one place, why not workload identities?
SPIRE Goodies: Plugins, k8s-workload-registrar, OIDC, etc.
Being built on top of SPIFFE/SPIRE means that it comes with all the awesome additional features, this includes plugins, such as attestation plugins such as different cloud providers’ node attestors, k8s workload attestor, etc. Additional services such as the SPIRE k8s workload registrar also provides a way for workloads in kubernetes to automatically be registered with the SPIRE server.
Another highlight is the OIDC integration that is possible with SPIRE, meaning that it is easy to configure services like Vault or any other IAM system to leverage the identities managed by Tornjak/SPIRE.
Upcoming Features — Contribute!
Tornjak is still in development, but we have many features which are on the way! Some of the highlights are:
- Policy control of Registration RBAC: Enforce all the workload identity registrations in a spot. Create policies and Open Policy Agent (OPA) rules around identities that can be registered to have assurance that all workload identities follow organizational and compliance policies. (based on SPIRE#2416)
- Logging integration: Keep track of how identities are provisioned and detect and flag anomalies. integration with logging systems will augment the information on workload identities.
If this interests you, we would love to have you contribute to the Tornjak and SPIRE projects! You can do that by checking out the Tornjak github repo, and comment on this issue to express interest.
Stay tuned for upcoming blog posts and features!
