EuProGigant: Policy as Code in Data and Service Ecosystems

Results

The developed concept shows how a policy-as-code can be implemented for data sharing, how it is integrated into services providing, consuming, and storing data, and, most importantly, how such a policy system is maintained over time. We developed different policies for different parties and kept them structured and readable for non-developers. Technically inclined people can understand what could happen to their company's data. 

The concept allows us and our partners to develop policies further and align them with changing interests.  The approach taken with extending the tooling (OPA) enabled us to incorporate Gaia-X standards (Gaia-X entities and partly their proposals for data contracting). 

Solution

The task at hand was to create a concept that would provide all parties with the means to control and understand what happens to their data. The idea was to transfer the policy-as-code approach we know from our day-to-day operations as cloud and DevOps engineers to the authorization layers of the data exchange in this manufacturing use case. 

​

Our experience building authorization systems shows that creating good systems with only simple examples is hard, as the challenges only become visible in realistic and more complex situations. Therefore, we developed a state-of-the-art service and authorization architecture. This testbed's features regarding data exchange were creating, reading, updating, and deleting (CRUD) product carbon footprints and requesting estimates. We added an organizational management layer: companies manage their employees and groups. On the technical side, we integrated open policy agent (OPA) at different levels of the stack. The setup allowed us to edit and evaluate policies quickly, add functionality (extensions) to OPA itself, and easily adapt the integration within the test application. ​

​

We created a realistic testbed to ensure the concept can be applied in a realistic scenario. 

We implemented and iterated on policies controlling who can use a service at all (admission policies), who can access data (access policies), how data must look regarding structure and values when created (content policies), when and if data can be deleted (retention policies), and what characteristics a service must have for company employees to use it (usage policies). 

For example, we implemented different rules for access control, a subset of which is illustrated in the following wireframe graphic. It shows three different ways to allow access to PCFs: one based on information about the customer provided ahead of time to the policy agent, one based on verifiable credentials provided by the customer, and one where the customer provides a valid agreement establishing his right to read the PCF.  

​

Depending on the policies, they were managed by service administrators, data providers, or data consumers. Shared management, where administrators set minimum requirements and data providers refine them, is part of the concept. 

Challenge