Thycotic Extends Secrets Management Reach to Kubernetes
Thycotic, a provider of privileged access management (PAM) platform, today announced its support for Kubernetes.
The company currently provides two types of PAM platforms for application developers. The first is DevOps Secrets Vault, which provides DevOps team with a mechanism to issue and manage secrets as applications or individual microservices are created and deployed.
The second offering is Secret Server, which provides a means of storing application credentials in a way that eliminates the need for developers to store secrets within an application where they might be easily compromised.
Billy VanCannon, director of product management for Thycotic, says developers of microservices-based applications that are deployed on Kubernetes clusters need to secure each one as it is being deployed. Thycotic addresses that requirement via a DevOps Secrets Vault platform that provides instant availability of secrets, SSH keys, certificates, application programming interface (API) keys and tokens.
Thycotic is extending that capability by employing a “mutating admission webhook” in Kubernetes to patch secrets using data ingested from either Secret Server or DevOps Secrets Vault, which eliminates the need for separate sidecar containers to be deployed on a Kubernetes cluster.
As a result, DevOps teams can employ a single PAM platform to centrally manage privilege policies across multiple types of applications, notes VanCannon.
Both Secret Server and DevOps Secrets Vault are designed to be integrated with other DevOps tools, including Jenkins, HashiCorp Terraform and Red Hat Ansible. Software development kits (SDKs) for programming languages including Java, Go, Python and .NET are also available.
In general, certificates have become especially challenging for DevOps teams to manage. An SSL certificate can usually be issued in minutes by a certificate authority. However, that’s typically not fast enough for organizations that have adopted DevOps. Organizations that have adopted DevOps will need to automate the process for requesting a certificate from within their continuous integration/continuous delivery (CI/CD) platform. Containers deployed in Kubernetes environments exacerbate this issue even further because they are created in near real-time. As microservices are constructed using containers, each certificate needs to be created on-demand. Each task typically requires its own certificate so the total number of certificates that need to be managed increases as well.
In addition, there are multiple types of certificates that might be employed, each of which may expire at some point that DevOps teams are supposed to track. It’s not uncommon for applications to suddenly be unavailable because a certificate used to encrypt it expired without anyone realizing the deadline to renew that certificate had passed.
In general, there’s a lot more attention being paid today to software supply chains, which includes who on the development team has permission to access specific modules of code at any given time. The challenge is finding a way to ensure the integrity of the supply chain without slowing down the rate at which applications are being developed and deployed.
