For an on-call engineer, there are few things more fear- inducing than an alert with the words “certificate expired”. I’ve been woken up countless times by unseen, expiring certificates nested deep in the infrastructure, triggering a flood of connection issues. Sometimes the cause was automation failures, but more often than not the certificate was manually-provisioned without a plan for renewal.
I don’t believe this is an isolated problem. I’m not exaggerating when I say that every company I have worked for has at least one, often multiple, internal CA deployments. All of them incurred outages that affected customers. One startup had a veteran security engineering team building custom CA tooling, yet we still had an extended outage due to an expired root certificate.
In our previous article, we talked about why we think there is an opportunity for internal TLS with ACME to be the best choice for application encryption. But if your experience with private CAs is anything like mine, the idea of using one is off putting. Why do private CAs conjure strong associations with toil, incidents, outages, and drained productivity? We believe this has little to do with the service they provide, and everything to do with their intended audience.
All CA products have roughly the same set of baseline requirements: strong security, audit-ability, role based access, extensibility, and so on. Some tick more boxes, others less, but they are all built for seasoned security teams. This is an audience that already has a strong understanding of CAs, how the underlying protocols (like TLS) work, and how a well run CA should be operated.
What’s missing is a product built for developers who are not dedicated to security. These users need a product that meets those baseline requirements while removing the need for them to be security experts. That is why we are building Anchor with the following properties in mind.
Developer Oriented
Encryption is too critical in 2023 for developers to completely outsource to operations and security teams. At the same time, developers have to be empowered and benefit from integrating encryption. Mapping encryption problems (traditionally solved with secops solutions) to developer solutions is the best way to achieve this.
First-class language support through native APIs and language packages.
Encryption that leads to simpler architectures, not increased complexity.
Automation & provisioning based on API tokens, not dealing with keys and certificates directly.
Bring maintenance & upgrades into CI/CD pipelines.
Encryption Dev/Prod Parity
Encrypting application traffic is often overlooked while talking about Dev/Prod parity. Developers need local access to encryption infrastructure in their development environments to build stable systems in production. Stability in production starts with confidence in the development environment.
Integrating application encryption must be the same for all environments, including development.
Local access to encryption infrastructure should not be a burden or point of friction.
Maintenance as a Forethought
Encryption infrastructure typically has high maintenance requirements, but when planned for from the outset, maintenance can follow very normal schedules. When done properly, a well designed maintenance schedule can practically eliminate the toil of operating these systems.
Regular schedules for credential rotation, artifact generation, and upgrade windows.
Must be highly automatable for quick incident response.
Proactive and ongoing maintenance notifications.
Beyond Baseline
Anchor centers on the service or application being encrypted instead of on the encryption itself. By focusing on the developer and developer experience, Anchor delivers a very different product than your mental model of a CA. This is a security product built for application developers.
In our next post we’ll showcase Anchor and how it is able to deliver the desirable properties outlined. If you want to share your thoughts or learn more, come join the discussion in our discord community.
