Article

Security vs. Speed:

How to Implement a Secrets Manager Without Fighting With Your DevOps Team

  • Illustration

    Author: Maksym Tkachenko, Senior Sales Engineer, BAKOTECH

Do you know which meeting in a company usually becomes the most emotional? The one where the Information Security department and the DevOps team sit down to discuss how secrets will be managed from now on.

As a distributor engineer, I regularly attend these meetings. On one side of the table sits the CISO, who has nightmares about data breaches and hackers. On the other side is the Lead DevOps engineer, whose KPIs depend on running 50 deployments a day and keeping CI/CD pipelines stable. They speak different languages. Security says, “We’re strengthening protection. From now on, all passwords must be stored in our secure enterprise vault.” DevOps rolls their eyes and thinks, “Well, here we go again. Security is about to break our entire release process.”

The core problem is this. We’ve become good at protecting living human beings — the administrators. We deploy PAM, enforce multi-factor authentication, and record admin sessions. But the paradox is that in modern companies, every human admin is accompanied by 40–50 “robots”: microservices, scripts, Ansible playbooks, Jenkins jobs.

They also need passwords, API keys, and tokens to access databases and services. So where do they get them? Most often, these credentials come from plain text files, environment variables, or — worst of all — are hardcoded directly in GitHub or GitLab repositories.

When security teams discover this, panic begins. They try to force traditional PAM tools into DevOps workflows. And this is where things get interesting.

The Black Friday Case

I remember one particularly vivid case. A large fintech company decided that all its Kubernetes containers would retrieve database passwords through the REST API of a traditional CyberArk Vault. Architecturally, it looked great on paper. Then Black Friday arrived. Traffic surged. The Kubernetes cluster automatically scaled up and launched another thousand containers to handle the load. And every one of those containers simultaneously called the Vault API to retrieve its password.

What happened next? A classic self-inflicted DDoS attack. The heavyweight enterprise vault that worked perfectly for a hundred administrators simply collapsed under thousands of machine requests per second. Containers couldn’t get their credentials. The application failed. The business lost money. After that, DevOps said, “We warned you,” and implemented a workaround that cached passwords in plain text.

And what was the result? Security effectively dropped to zero.

This is a classic example of why tools built for humans do not work for machines. Machines require speed, scalability, and native integration.

Secrets Manager: Not a replacement, but an extension

That’s precisely why a new category of solutions has appeared on the market – Secrets Managers (for example, CyberArk Conjur). This isn’t a replacement for your core PAM system. It’s a logical extension, a high-speed courier for secrets.

The idea is to reach an architectural compromise that we advocate in many pilot projects: give each team what it needs.

The security team keeps its single source of truth – the classic vault. That’s where passwords are rotated, policies are configured, and ISO 27001 audits are satisfied. But instead of forcing developers to access this vault directly, we deploy a lightweight, horizontally scalable Secrets Manager within the DevOps environment. It retrieves secrets from the vault and delivers them to containers within milliseconds.

Even better — it does so natively. Developers don’t need to rewrite their code to work with a new security API. The Secrets Manager injects the required credentials directly into the container’s memory during startup. Developers continue writing code the way they always have. Pipelines remain fast, and releases keep moving.

DevOps culture doesn’t tolerate workarounds. If security creates friction, it will be bypassed. The successful projects we see in distribution are built not on restrictions, but on integration. When a security tool works under the hood and speaks the developer’s language, the conflict disappears, and real engineering work begins.