Release without fear on your own infrastructure

What the regulation requires, and what it doesn't

Many institutions keep systems and data on their own infrastructure, because of their risk model, their contracts or their legacy systems. They are not a minority: in the CNCF's 2024 survey, 59% of participants use self-managed on-premises infrastructure, the same share as self-managed public cloud (750 participants from its community). Running in-house is no excuse for releasing without discipline.

One point worth having clear in front of any committee: in general, Mexican regulation does not require infrastructure to be in-house. The CNBV rules for banks allow own or third-party infrastructure, even abroad, with requirements that depend on the service: prior notice or authorization, continuity if the provider fails, and the authority's access to the information. The personal data law does not set a mandatory location either, although it does set conditions for processing and transfers. The details are validated for each entity and each service.

What these frameworks do ask for is that you demonstrate control: evidence and traceability proportionate to the risk. Keeping the infrastructure in-house does not guarantee it. What changes is responsibility: in-house, all the control and all the mitigation are yours. If the path to production is well built, that control is shown with evidence, not with promises.

Does your current infrastructure let you demonstrate that control with the same discipline as a public cloud? Cloud & infrastructure

What comes insecure out of the box

A cluster that passes its functional tests can fail a security audit if it keeps its factory configuration. According to the official Kubernetes documentation and the NSA and CISA hardening guide, several things come this way by default:

• Secrets are stored unencrypted in the cluster's database.
• The audit log is off.
• Namespaces do not isolate the network: without explicit policies, everything talks to everything.
• In clusters created with kubeadm, client certificates expire after one year by default. They are renewed with upgrades or with an explicit procedure; if nobody does it, the cluster stops responding on some ordinary day.

And there is a physical one that almost nobody measures: the cluster's state store (etcd) is very sensitive to disk latency. Its hardware guide gives as a reference 50 sequential operations per second, and 500 for loaded clusters, and recommends a solid-state disk. With high or highly variable latency, the symptom is not "it's slow": it is timeouts, leader elections and availability drops. It is measured with representative load tests, before production.

Could anyone on your team tell you today, without looking it up, when your cluster's certificates expire?

A single path to production

From the developer's change to production, everything goes through the same path, and every gate can stop the release:

1. Tests that stop. Mandatory tests block promotion; inconclusive signals are recorded and handled under an explicit policy. For an emergency there is an exception procedure, with approval and a trail.
2. Quality with the reason in plain view. The gate is not satisfied with "it finished fine": it says which condition failed.
3. Scanning by category: code, dependencies, exposed secrets, images and configuration, with thresholds and traceable exceptions. And it tells "it found something" apart from "it did not finish checking": both stop the release.
4. Build once, promote the same thing. What was tested is what reaches production; nothing is rebuilt per environment. Each environment's configuration and secrets are controlled separately, with versions and a trail.
5. Fail early and clearly. If the build server is missing something, it fails at the first step and says what is missing.

What does your process check today before reaching production, and what does it let through without anyone noticing? DevSecOps

Without internet, the scanner ages too

On an isolated network, the part that gets neglected most is the quietest one: the scanner's vulnerability database. If nobody updates it, the scanner keeps saying "no findings" because it doesn't know about anything new. Some tools refuse to run with a database older than five days; others stay green with a frozen database. A well-built isolated path brings its own mirror of those databases, with a visible date and an alert when it gets old.

Does your scanner know about the vulnerabilities published this week? DevSecOps

Three destinations, the same criterion

Gates and evidence are reused across destinations; each destination keeps its own deployment, identity, monitoring and recovery requirements, and moving to Kubernetes requires redesigning several of them.

Which of the three is yours today, and which should it be in two years?

Failures we see often

• Duplicated, ungoverned release processes. When each team maintains its own copy, the copies drift apart silently and the evidence stops being comparable. Better a single shared, versioned template.
• Installing by hand from the build tool. Mixing "who builds" with "who installs" leaves changes without a trail. Better to separate them and describe the environment as code.
• Temporary exceptions that become permanent. A control skipped "just in development" is the one that later fails in production.
• Loose identities. The orchestrator's own directory, separate from the company's, accumulates orphaned accounts with high privileges (NIST SP 800-190).

Other controls that are usually relevant —secrets management, signing and inventory of what is released, human approval for production, segregation of duties, recovery and retention— are defined according to your risk model.