How are Kubernetes Secrets managed with Red Hat?
This section will discuss the three main components of Kubernetes Secrets management in Red Hat® OpenShift®: repositories, distributors, and consumers. Understanding what role each of these components play in the management of credentials on a Kubernetes cluster is critical to improving the security posture of the cluster as well as reducing the cost of maintaining these systems. Kubernetes administrators will care about the impact of these tools on their clusters’ performance while DevSecOps teams will want to ensure that secrets are passed to the cluster in the safest possible manner.
What will you learn?
- What are Kubernetes Secrets repositories, distributors, and consumers
- How they interact with each other
What are secrets repositories?
A secrets repository is any tool that provides a centralized place to store credentials. This could be as simple as having a GitHub repo that uses sealed-secrets to encrypt credentials before they are stored in the repository, or adopting more complicated tools like CyberArk Conjur, HashiCorp Vault, or other secrets management platforms provided by cloud service providers. Regardless of complexity, secrets repositories must include the ability to audit credential usage and lifecycle in production, as well as a way to manage credentials in the case of a breach or other triggering event. A strong repository should also have a robust API for obtaining credentials.
In most cases, the secrets repository will exist separately from the Kubernetes cluster. However, they can also be installed on a Kubernetes cluster, using namespace isolation and RBAC to limit access to the repository from other users of the cluster.
Red Hat works primarily in the secrets distributors space, providing customers with the necessary elements to obtain credentials from almost any secrets repository and make them available to workloads and applications running on the cluster.
What are secrets distributors?
A secrets distributor receives requests from applications for credentials, and then forwards these requests to the secrets repository. When a request for a credential is received, a strong secrets distributor will authenticate the request with the secrets repository via well defined APIs. Once the credential is confirmed and obtained, the distributor will make the credential available to the application in the form necessary for the application to consume it.
Red Hat uses an operator and plugin architecture to allow for better role isolation for a secrets distributor. The operator receives requests from applications and makes retrieved credentials available to the application. The plugin, which should be provided by the same vendor who developed the secrets repository, authenticates the request with the repository and retrieves the credential.
What are secrets consumers?
Secrets consumers are any application or workload running on the Kubernetes cluster that requires credentials to operate. This could include Red Hat products such as Red Hat Quay or Red Hat OpenShift Pipelines, or third party products such as a SQL database or CRM. Depending on how they are developed, each of these applications may require the credential to be supplied in a different format (e.g., environment variable, configuration file, etc). Additionally, each of these applications may also come with different security features, such as short-lived tokens for Red Hat Quay pull secrets.
You are now ready to learn how to manage Kubernetes Secrets in Red Hat OpenShift.
