Security problems are experiencing a ‘shift left’ as secrets management is increasingly being moved into the CI/CD pipeline. But without properly securing the automated build, test and deployment tools of DevOps, those secrets could leak. In this blog, we will walk through how secrets define identities, the challenges of securing identities within DevSecOps automation, and what can be done to ensure their safety within that environment.
Identity means secrets
You prove identity by validating credentials; secrets are the digital credentials used for that purpose. With the proper validation, you can authenticate a user (human or machine) and authorize them to access privileged services, accounts, and applications. Therefore, securing secrets is a priority because internal network access rests on secrets.
As machines and humans both have identities that require authentication, the list of credentials to keep track of and protect can include:
- API credentials
- GitHub tokens
- Hard-coded credentials in containerized applications
- Private encryption keys (PGP protocols)
- SSH keys
- TLS/SSL certificates
- One-time password devices
To ensure the safety of these credentials, developers first need to know where they are within the Continuous Integration, Continuous Delivery (CI/CD) pipeline, and then how to configure, manage and deploy the credentials correctly. As you can imagine, the number of identities requiring validation within a fast-moving DevOps environment can by myriad.
Why securing secrets in the CI/CD pipeline is tough
DevOps is born of speed, and to that end, technologies like Ansible, Puppet, Chef and Jenkins are used to bring process and product closer together. However, to be able to do so, these tools must be the hub of thousands of services, machines and applications that comprise the Development and Operations lines.
It’s no surprise then that “CI/CD tools are the biggest consumers of secrets and have access to a lot of sensitive resources such as other apps and services and information like codebases and databases,” as Identity Defined Security Alliance states in a recent blog post. And “as the number of secrets grows, it becomes harder to store, transmit, and audit secrets securely.”
The problem is exacerbated by the complexity of the development process as well. While once you only needed to authenticate between tools, now it is not uncommon for virtual machines, services, or other resources to be able to authenticate to each other during the build process, just to get the job done. As Identity Defined Security Alliance states, “this is particularly important in hybrid cloud and microservices deployments, and with the automated scaling capabilities of tools like Kubernetes.”
Processes need to stay agile, and if authenticating during build time is cumbersome or friction-heavy, chances are those security processes (as important as they are) might get overlooked, carelessly done or omitted entirely.
What can be done to ensure we keep the ‘Sec’ in DevSecOps, without compromising speed, efficiency and agility?
Protecting identity within CI/CD
To secure your CI/CD pipeline and all secrets on it, you need complete visibility and monitoring across the length of the toolchain. This includes locking down configuration managers, systems where repositories are hosted, and build servers. Here are several best practices:
- Leave no trace. Erase hard-coded secrets from CI/CD configuration files and source code.
- Identify access permissions. In other words, know who can access what and on what rules the access stands – be it based on role, time or task. Or you can segment your secrets based on broad access management permissions.
- Exercise the principle of least privilege. If they do not require access to the resource based on a critical job function, they should not have it. No one should be allowed any excess permissions by default - it widens risk and provides no reward.
- Manage machine identitieswithin containers. A requesting client runtime container will need to validate to native characteristics of a valid container, so it is key to ensure secure authentication in that exchange. It is also best practice to destroy containers and virtual machines after use.
- Use one-time passwords or other methods of Modern Authentication (biometrics, MFA, location-based validation) where possible when dealing with highly sensitive tools, systems and information.
- No double dipping. Make sure your secrets are not accidentally passed along for pull requests during builds.
- Use a password manager, to create brute-force resistant passwords, and distinct passwords for each service when dealing with human identities.
- Use a Machine Identity Management Platform when it comes to managing machine secrets in your CI/CD pipeline. It acts as a password manager for machines, while automating renewal, revocation and configuration of TLS-based authenticators. It can also find, catalogue, and control all machine identities across your enterprise – on-prem, in the cloud and across virtual environments – so you can manage machine secrets from a single pane of glass.
How TLS Protect for Kubernetes enables DevSecOps
Managing identities – both human and machine – within the context of a DevOps environment is an inevitable reality of the digital revolution.
TLS Protect for Kubernetes is the cloud native machine identity management solution that provides automated PKI protection at the speed of DevSecOps. It gives you control and visibility over your X.509 certificates, allowing you to control their configuration status automatically across Kubernetes and OpenShift clusters. TLS Protect for Kubernetes provides developers a consistent deployment process with workload security built in, rooting out poorly configured certificates and alerting you so you can take action to defend your secrets.
Use TLS Protect for Kubernetes to proactively monitor ingress from inside the cluster and get ground-level visibility that allows you to use your existing PKI to control workload security across the service mesh.
Keeping track of secrets – be they human or machine identities – across today’s complex architecture is only possible with the right solutions. As organizations rush to the cloud, hybrid environments, containerization, virtualization and everything else encompassed in the DevOps sweep, it is important that security maintain a primary role.
TLS Protect for Kubernetes gives you the automated security solution designed to keep up with change and allow you to continue to evolve quickly, viably and securely into the digital age.
Learn more about how TLS Protect for Kubernetes protects your CI/CD pipeline, by getting in touch with one of our experts today.