OPA and SPIFFE - two new projects at CNCF for cloud application security

At the end of March, CNCF, which helps develop open source projects for cloud (cloud native) applications, has double replenishment: OPA (Open Policy Agent) and SPIFFE (Secure Production Identity Framework For Everyone) have been added to the sandbox security topic. What are they for?

Open policy agent

Open Policy Agent ( GitHub ) - written in the Go language engine, offering a unified way to use policies that are context sensitive and work across the entire infrastructure stack used for cloud applications.
')

The initiative to create the Open Policy Agent comes from Netflix. As her representatives told at CloudNativeCon US 2017, this project allowed to solve the problem of authorization in the scale of a large cloud environment. In short, the company's engineers wanted to provide a standardized (and simple) ability to define and enforce rules of the following type: The subject (identity, I) can / cannot perform Operation (operation, O) on the Resource (R) - in all possible combinations across the entire ecosystem.

At the same time, as it is easy to guess, the Netflix ecosystem is very diverse: there are not one type of resources (REST interfaces, gRPC-methods, SSH, Kafka topics, etc.), more than one type of subjects, as well as many protocols used (HTTP / HTTPS, gRPC, its binary), programming languages ​​(Java, Node.js, Python, Ruby) ... Finally, the critical requirement for this whole system is the minimum delay : for example, one node of the Kafka cluster processes thousands of requests per second, so about the layer , requiring more than 1 millisecond for authorization, and there could be no question.

The general scheme of the solution, which came to Netflix, was the following:


And in a more detailed view, the architecture of the system using OPA looks like this (slides taken from this presentation ) :





Policies in OPA are written in a high-level declarative language (it is called Rego) and loaded via a file system or API. Services transfer the responsibility for making a decision on policies by request to the Open Policy Agent engine, which scans policies and additional data, makes a decision on request and returns it to the client. Application integration with OPA can be implemented by different methods: sidecar-container, host-level daemon, library. According to the authors, for simple policies, the average delay is about 0.2 ms.

The simplest illustration of using the API from the Open Policy Agent is presented in the GitHub project :

Users can view their salary and the salary of employees subordinate to them:

allow { input.method = "GET" input.path = ["salary", id] input.user_id = id } allow { input.method = "GET" input.path = ["salary", id] managers = data.management_chain[id] id = managers[_] } 

Query: Can Bob see his salary?

 > input = {"method": "GET", "path": ["salary", "bob"], "user_id": "bob"} > allow true 

Query: Chain Managers for Bob.

 > data.management_chain["bob"] [ "ken", "janet" ] 

Query: Can Alice see Bob's salary?

 > input = {"method": "GET", "path": ["salary", "bob"], "user_id": "alice"} > allow false 

Request: Can Janet see Bob's salary?

 > input = {"method": "GET", "path": ["salary", "bob"], "user_id": "janet"} > allow true 

Details about the OPA device, as well as about working with this engine, are described in the project documentation . You can also find examples of integration with Admission Controllers in Kubernetes ( K8s version 1.9+ required and included ValidatingAdmissionWebhook ) , with Docker (Docker Engine 1.11+ required), and with SSH (using a Linux-PAM plugin) .

Secure Production Identity Framework For Everyone

The authors of SPIFFE ( GitHub ) differently approached the problem of authentication - they offer the framework’s web services and a set of standards that eliminate the very need for authentication and authorization at the application level, as well as in complex configurations of access lists at the network level.

The basis of SPIFFE consists of three components:

1. SPIFFE ID . A standard that defines how services identify each other. These are structured strings (represented as URIs - for example, spiffe://trust-domain/path ), acting as names for the entity.
2. SPIFFE Verifiable Identity Document (SVID) . The standard for converting SPIFFE IDs into a cryptographically verifiable document (this document is called SVID). The specification is defined in The SPIFFE Identity and Verifiable Identity Document . In addition, there is a separate specification for X.509 SVID .
3. Workload API . API specification for issuing and receiving SVIDs. As a rule, API methods are available locally (for example, via a Unix domain socket) and do not require authentication from the workload. The authenticity of accessing the Workload API can be verified by a third-party method (for example, by the properties provided by the operating system of the process that accesses the socket). In addition, the Workload API provides certificates (CA bundles). Work on the specification is still underway (a prototype is available).

The architecture of environments using the approach proposed in SPIFFE is represented as follows:



In addition to the actual specifications, as well as related examples and other documentation stored mainly in the project repositories , the authors prepared a reference implementation of their basic components - SPIRE (the SPIFFE Runtime Environment). Its code is written in the Go language and is a bundle of a server and an agent that represent the SPIFFE Workload API in action, i.e. allow you to certify software systems (workloads, "workloads") and give them SPIFFE IDs and SVIDs.

The SPIFFE Workload API is similar to the AWS EC2 Instance Metadata API and the Google GCE Instance Metadata API in the sense that it does not require prior knowledge of the subject or an authentication token from the caller. However, the authors point out important distinctive features of their development: 1) it runs on multiple platforms, b) it allows you to identify running services not only at the process level, but also at the kernel level, which allows it to be used with container schedulers like Kubernetes. To minimize the consequences of key leakage / compromise, all private keys (and corresponding certificates) do not live long and are subject to frequent (automated) rotation. Read more about the SPIRE architecture here .

In addition, the project has libraries on Go ( go-spiffe ) and C / C ++ ( C-SPIFFE ).

Work on SPIFFE is conducted within the SIG (Special Interest Groups) groups, by analogy with Kubernetes. The experts who lead them are employees of Scytale companies (initiators and main authors of the project), Google, Pensando and Blend. In particular, there are groups that integrate SPIFFE with Kubernetes , gRPC and AWS .

The SPIFFE website states that the project "is in the early stages of implementation and is not yet ready for use in production."

PS

Read also in our blog:

• " CNCF Guide to Open Source Solutions (and more) for cloud native ";
• “ Four releases 1.0 from CNCF and major announcements about Kubernetes from KubeCon 2017 ”;
• “ Rook is a“ self-service ”data store for Kubernetes ”;
• " CoreDNS - DNS server for the cloud native world and Service Discovery for Kubernetes ";
• “ Container Networking Interface (CNI) - network interface and standard for Linux containers ”;
• " Infrastructure with Kubernetes as an affordable service ."