Platform engineering promises to enable enterprises to ship software faster, while making their setup more secure and compliant in the process. Developers can self-serve the infrastructure they need without having to wait for operations teams. Ops and platform teams can define clear configuration templates and golden paths that are automatically enforced by the platform (or the Platform Orchestrator, to be specific).
Sounds great right? And it is. But you might wonder: “Hold on a second, how can all this developer self-service thing really be secure?”. How can you let engineers interact autonomously with different resources like databases and DNS and be sure that all those passwords and secrets are actually safe? After all, you don’t want to be added to the long list of companies that stored passwords in plain text or left secrets publicly accessible via checked-in IaC.
In this article we’ll explain how the Humanitec Platform Orchestrator can automatically generate application and infrastructure config files and deploy them to your Kubernetes clusters, without needing to access your secrets. Let’s dive in.
The Platform Orchestrator: a graph-based backend for your platform
Before we get to the secrets management bit, a quick refresher on the architecture of the Platform Orchestrator.
In the graphic below you’ll see how platform engineers can use our open source Resource Definitions and respective matching criteria to define rules for how developers can consume infrastructure. Developers can describe in an abstract way what they need through any interface (CLI, UI, API or, in this case, Score), e.g. "my workload needs a Postgres".
The Platform Orchestrator reads the request and matches it to the rules defined by the platform team (for context = “staging” and resource = “postgres”, use the Resource Definition = “postgres-rds-stg”). It then creates a graph-based representation of the workload and its dependencies, using the Resource Definitions mentioned above.
Now that we are on the same page as to how the Platform Orchestrator works, it’s also important to mention every file involved in the process outlined above should use Placeholders.
Whether you are working with your Resource Definitions in a repo, setting environment variables in the Portal UI or describing workload dependencies in a Score file, you never want to hard code secrets in any of them.
If we stick to the same example and zoom into the Score file, you’ll notice Placeholders are used to describe User, Password, etc. for the Postgres database.
Placeholders will be resolved by the Platform Orchestrator at deployment time against your stored secrets.
How Humanitec keeps your secrets (without actually keeping them)
The Humanitec Platform Orchestrator is designed to be used in any enterprise environment. Being a SaaS solution, it even works with your Kubernetes clusters and infrastructure on private networks using the Humanitec Agent.
In either scenario, the Platform Orchestrator doesn’t need access to your secret store, thanks to the Humanitec Operator. The Operator sits inside your K8s clusters and securely complements the operations performed by the Platform Orchestrator.
Once configured to work with your external secret store, the Platform Orchestrator renders the manifests only partially, while also generating a set of instructions describing how to complete the rendering procedure. These are received by the target K8s cluster in the form of Custom Resources (CRs). The Humanitec Operator picks up the CRs and completes the remaining rendering stages, calling any required Drivers to provision infrastructure and obtaining secrets from your own secret store.
This ensures your secrets are never shared outside your secrets store and clusters. You don’t need to (and shouldn’t) hand them over to Humanitec, nor to your developers or platform team. This is also much safer than relying on a pipeline-based design for your platform backend. If for example you wanted to use GitHub Actions for your deployment pipeline, you’d have to give GitHub access to your secrets, losing control over them in case your GitHub gets hacked.
Recap
Humanitec can securely integrate with your existing secrets management solution thanks to the Humanitec Operator. The Operator can perform the following actions:
- Reads CRs when they are created/updated
- Creates K8s manifests
- Obtains secrets from the secret store
- Calls Drivers to provision or update infrastructure
- Resolves Placeholders in the target K8s cluster
- Populates status information for the Platform Orchestrator to read
If you want to dive deeper into the Humanitec Operator, check out our docs.
