Secure by Design - Part 1

Why Modern Platforms Cannot Be Secured Retroactively

The discussion about IT security is still dominated by a misconception. Security is often seen as an additional layer applied to existing systems. Initially, applications are developed, infrastructures are built, and automation processes are established. Only then do firewalls, vulnerability scanners, endpoint protection, or compliance measures follow.

This model might still work acceptably in a world of static systems. However, in modern platform architectures, it inevitably leads to problems.

Cloud-native environments today consist of thousands of infrastructure components that are continuously created, modified, and removed. Kubernetes clusters are set up within minutes. Terraform automates the provisioning of entire cloud landscapes. Ansible configures operating systems and middleware on a large scale. GitOps pipelines deploy changes hundreds of times a day.

In such an environment, security is no longer a downstream function.

It must be an integral part of the architecture.

This is precisely what the term Secure by Design describes.

The Real Attack Surface Is Not in the Infrastructure

When talking about attack surfaces, many initially think of public endpoints, databases, or applications. Technically, however, the most critical component is often located elsewhere.

In the automation layer.

Modern infrastructures are no longer operated manually. Control now lies in Terraform projects, Ansible playbooks, CI/CD pipelines, Kubernetes manifests, and the platforms that orchestrate these tools.

Anyone who gains access to this level often no longer needs direct access to production systems.

The automation already has this access.

A compromised deployment system can manipulate applications. A faulty Terraform execution can change security policies. A compromised Ansible system can configure thousands of servers within minutes.

From a security perspective, the automation layer is not an auxiliary system.

It is critical infrastructure itself.

Why Traditional Automation Approaches Create Security Issues

Many companies have impressive automation landscapes. Terraform is used, Kubernetes is operated, and Ansible is widely utilized.

Yet, a problem often arises that initially remains invisible.

The tools are standardized.

The execution environments are not.

Administrators use different versions of Terraform. Developers work with individual Python dependencies. Teams install their own Ansible collections or use local extensions. Playbooks are executed from workstations whose state varies from user to user.

The consequences usually only become apparent later.

A deployment behaves unexpectedly. An infrastructure change produces different results. An incident cannot be fully reconstructed.

The cause often does not lie in the code itself.

It lies in the runtime.

These differences initially appear operational.

In reality, they have immediate impacts on security.

Reproducibility Is a Security Requirement

In software development, a fundamental principle has been established for years:

An identical build must produce identical results.

Surprisingly, this concept is often not consistently applied in infrastructure automation.

The consequences are severe.

If the same Terraform configuration produces different results depending on the local environment, there is no complete control over the target state. If different Ansible versions can create different configuration states, infrastructure behavior becomes difficult to predict.

Security, however, is based on predictability.

A system whose behavior is not clearly reproducible can only be controlled to a limited extent.

Therefore, the containerization of runtime environments is gaining importance. Not only is the infrastructure definition itself versioned, but also the entire execution environment. Terraform, OpenTofu, Ansible, kubectl, or Helm are executed within defined and reproducible container runtimes.

The runtime thus becomes part of the architecture.

No longer part of the individual workstation.

Governance Often Fails Due to Lack of Transparency

Another problem with modern automation landscapes is that while changes occur, their origin is difficult to trace.

Who executed a particular change?

Which version of a playbook was used?

What runtime was employed?

Which target systems were affected?

What credentials were used?

Many organizations can only answer these questions with considerable effort.

This is problematic.

Not only from a compliance perspective but especially in security incidents.

Incident response is based on context. The better the origin of a change can be traced, the faster impacts can be assessed and countermeasures initiated.

Auditability is therefore not a regulatory exercise.

It is a security mechanism.

The Underestimated Risk: Secrets and Privileged Access

Few areas in infrastructure platforms are as frequently underestimated as the handling of privileged credentials.

API tokens, SSH keys, cloud credentials, or certificates form the trust basis of almost every modern infrastructure.

At the same time, these pieces of information often end up in places where they should never have been.

In local home directories.

On developer machines.

In build systems.

Sometimes even in Git repositories.

The real risk does not arise from the secret itself.

The risk arises from the lack of control over its use.

Secure by Design means that identities, permissions, and secrets are not treated as side issues. They must be considered central platform functions.

A secure platform always answers the question of who can access which resources, when this access occurred, and what actions resulted from it.

Why Platforms Are More Important Than Tools

Terraform is not the problem.

Ansible is not the problem.

Kubernetes is not the problem either.

On the contrary.

These tools have established themselves as industry standards and are indispensable in modern IT landscapes.

The challenge lies on a different level.

Companies need not only powerful tools. They need a consistent operating model for these tools.

This is where platforms come in.

Platforms do not replace Terraform.

They do not replace Ansible.

They do not replace Kubernetes.

They create a controlled framework for their use.

Standardized runtime environments, central governance, reproducible executions, integrated auditability, and controlled handling of secrets are not features of individual tools. They only emerge at the platform level.

Polycrate follows this approach. Instead of abstracting individual technologies, they are brought together in a common execution layer. Infrastructure teams continue to work with the tools that have proven themselves in practice. At the same time, a platform is created that makes the use of these tools reproducible, traceable, and controllable.

Conclusion: Secure by Design Is an Architectural Decision

Many security measures only come into play once infrastructure already exists.

Secure by Design takes a different approach.

The question is not how systems can be secured retroactively. The question is how they can be designed from the outset so that risks do not arise in the first place.

The more complex modern platforms become, the more important the architecture of the automation layer becomes. This is where most changes occur today. This is where the highest permissions are concentrated. And this is where it is ultimately decided whether an organization controls its infrastructure or merely reacts to incidents.

Security therefore does not begin with the firewall.

It begins with the platform.