Secret Management Instance for Kubernetes Microservice Deployment
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In Kubernetes environments, deploying updated microservices and software containers requires numerous configurations and redeployment of secrets like tokens or private keys, which poses a security risk due to unsecured access and management challenges.
Innovation Solution
A method that splits secret information into parts, using a secret management instance to generate and distribute these parts among entities like continuous integration/delivery chains and secret stores, allowing only combined parts to generate the secret, ensuring secure access and management through algorithms like Shamir's secret sharing or XOR.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If secrets are stored centrally and accessed during deployment, then deployment process is simple, but security is compromised due to unauthorized access risks
Solution Approach 1:
The secret is divided into multiple secret parts (first secret part, second secret part, etc.) that are stored in different locations (continuous integration chain, secret store, trusted party). No single entity has access to the complete secret, thereby enhancing security while maintaining deployment simplicity through automated reconstruction.
Solution Approach 2:
A secret management instance acts as an intermediary that coordinates the distribution of secret parts to various entities (continuous integration chain, secret store, trusted party) and facilitates their reconstruction. This intermediary ensures secure handling without requiring any single entity to possess the complete secret.
2Reliability
If secrets are redeployed with each microservice update, then access control is maintained, but deployment complexity and time increase
Solution Approach 1:
Secret parts are pre-distributed to various entities (continuous integration chain, secret store, trusted party) before the actual microservice deployment. When deployment is needed, the secret parts are already in place and can be quickly reconstructed using the secret generation algorithm, eliminating the time-consuming process of secret redistribution.
Solution Approach 2:
The system enables self-service deployment where the pod instance automatically reconstructs the secret from the distributed secret parts using the secret generation algorithm without requiring manual intervention or centralized secret redistribution. This automates the process while maintaining access control.
3Adaptability or versatility
If multiple entities have access to secret parts, then system functionality is enabled, but security risk increases from multiple access points
Solution Approach 1:
The complete secret is segmented into multiple secret parts that are distributed to different entities (continuous integration chain, secret store, trusted party). Each entity only holds a fragment, making it impossible for any single entity to compromise the entire secret. This enables system functionality across multiple entities while mitigating security risks.
Solution Approach 2:
Different entities are assigned different secret parts based on their specific functional requirements. Each entity has access only to the secret part necessary for its operation, rather than having access to the complete secret. This localized access approach enables system functionality while reducing overall security exposure.
4Reliability
If secret information is generated and managed outside runtime environment, then security is improved, but deployment complexity increases
Solution Approach 1:
The secret management instance serves multiple functions: generating secret parts, distributing them to various entities (continuous integration chain, secret store, trusted party), and coordinating their reconstruction. This multi-functional approach consolidates complexity into a single management entity while maintaining security through external secret generation.
Solution Approach 2:
The secret management instance acts as an intermediary that simplifies the deployment chain by centralizing secret part distribution coordination. While it adds a management layer, it actually reduces overall complexity by providing a single point of control for secret lifecycle management rather than requiring each entity to independently handle secret generation and distribution.
Data Source
Figure 1~2
AI summary
The invention relates to a method for providing the functionality of multiple microservices and/or the functionality of multiple software containers by means of a cloud infrastructure, wherein with respect to the microservices and/or the software containers the cloud infrastructure comprises or is associated with a cloud domain and a continuous integration / continuous delivery domain, wherein the cloud domain comprises a cloud pod instance, wherein the cloud infrastructure furthermore comprises or is associated with a secret management instance and a container image repository, wherein, in order to deploy and operatively use a specific microservice and/or a specific software container as part of the pod instance, the pod instance needs to be provided with a secret information, wherein the method comprises the steps of: -- in a first step, the secret management instance generates a first secret part of the secret information and at least a second secret part of the secret information, wherein the secret information is able to be generated, based on a knowledge of the first and the at least second secret parts, by means of applying a secret generation algorithm, -- in a second step, the first secret part is provided, by the secret management instance, to a first entity or functionality, and the second secret part is provided, by the secret management instance, to a second entity or functionality, wherein the first and second entities or functionalities are chosen among -- a continuous integration / continuous delivery chain, -- a cloud secret store instance, -- a GitLab secret store instance, and -- a trusted party secret store instance, -- a further continuous integration / continuous delivery chain, -- in a third step, in view of the specific microservice and/or the specific software container being deployed and operatively used as a part of the pod instance, a respective container deployment information is provided to the pod instance, and an initialization of the container deployment information involves to use the first secret part and the second secret part to generate the secret information, based on the first and the at least second secret parts, by means of applying the secret generation algorithm.