Romuald Vandepoel

The abstract

NLnet Labs and Red Hat are closely following two legislative proposals from the European Commission applicable to almost all hardware and software on the European market;

• The Cyber Resilience Act (CRA), intends to cover products including digital elements, like software, with cybersecurity conformity requirements and obligations.
• The new Product Liability Directive (PLD) is looking to extend liability for defective products to the world of software.

The audience will learn about the CRA and PLD from different angles: from their respective authors at the European Commission, from a small, public benefit organisation producing and supporting upstream open source software, and from organisations promoting, using and distributing open source software.

The session will be divided in two parts:

• A series of lightning talks from representatives of the European Commission and NLnet Labs to introduce the subject.
• A panel, moderated by Red Hat, with participation from Digital Europe, the EC Open Source Program Office, Red Hat and NLnet Labs to share views and opinions about the future of open source software within the current and future legal framework.

The session will be split into two parts as follow:

Lightning Talks (~45min)

Topics:

• Introduction to the Cyber Resilience Act by Benjamin Boegel from DG-CNECT at the European Commission
• The Cyber Resilience Act from a NGO involved in open source by Maarten Aertsen, NLnet Labs
• Introduction to the new Product Liability Directive by Omar Ennaji from DG-GROW at the European Commision

Panel (~45min)

The panel theme is: How to proceed as a community?

Participants:

• Maarten Aertsen, Sr Internet Technologist, NLnet Labs
• Gijs Hillenius, IT Project Officer, EC DIGIT Open Source Program Office
• Zoey Stambolliu, Sr Policy Manager, Digital Europe
• Romuald Vandepoel, Chief Digital Advisor for Public Sector, Red Hat Inc.

supporting the panel:

• Benjamin Bögel, Policy Officer, EC DG-CNECT
• Omar Ennija, Legal and Policy Officer, EC DG-GROW

moderated by James Lovegrove, Public Policy Director, Red Hat Inc.

By design, Kubernetes will store secrets encoded in base64 within its etcd resulting in an insecure solution.
While a couple commercial and open-source solutions exist to solve this problem, they all call for a separate set of tools, skills and limitations along with hardstop from CISO and Security Architect. Kubernetes put in place a KMS provider plugin framework and Trousseau leverages it to solve the secret management using standard Kubernetes API secret objects and constructs.

While there are significant efforts to improve Kubernetes component layers, the state of Secret Management is not receiving much interests. Using etcd to store API object definition & states, Kubernetes secrets are encoded in Base64 and shipped into the key value store database. Even if the filesystems on which etcd runs are encrypted, the secrets are still not.

Instead of leveraging the native Kubernetes way to manage secrets, commercial and open source solutions solve this design flaw by leveraging different approaches all using different toolsets or practices. This leads to training and maintaining niche skills and tools increasing cost and complexity of Kubernetes day 0, 1 and 2.

Once deployed, Trousseau will enable seamless secret management using the native Kubernetes API and kubectl CLI usage while leveraging an existing Key Management Service (KMS) provider. How? By using using the Kubernetes KMS provider framework to provide an envelop encryption scheme to encrypt secrets on the fly.