Skip to content

Platform Security and Lifecycle

Security does not depend on a single component. It is applied in layers, so that the failure of one does not expose the whole application.

The platform's security layers, from the application down to the datacenter

Each layer covers what the one above lets through — and the level of protection can be adapted per environment, without requiring every application to use exactly the same configuration.

Worker operating system

The solution does not depend on a single Linux distribution. Worker nodes use the operating system appropriate for the project's compatibility and security requirements: minimal distributions, Cloud Native distributions, immutable systems, enterprise distributions or hardened profiles.

The selection considers application compatibility, attack surface, lifecycle management and compliance requirements. The objective is to keep the worker OS as a controlled platform layer, without unnecessary services and components.

Hardening applied can include:

  • minimal installation, with unnecessary services removed or disabled;
  • controlled updates, in a maintenance window;
  • restrictive filesystem permission policies;
  • restricted or disabled SSH access depending on the profile;
  • kernel hardening;
  • configurations aligned with CIS Benchmarks when required or contracted.

Kubernetes layer

At the platform level we apply:

  • least-privilege RBAC — service accounts with only what they need;
  • Pod Security Standards — restrictions on privileged containers;
  • namespace isolation — separation between teams, environments and applications;
  • non-root execution, with reduced Linux capabilities;
  • read-only root filesystem, where the application supports it;
  • resource policies — requests, limits and per-namespace quotas;
  • auditing and monitoring of the control plane.

Networking with Cilium

The cluster's networking layer uses Cilium, which allows connectivity and security to be applied directly to workloads, with identity-based policies instead of IP addresses:

Capability What it delivers
L3/L4 network policies Explicit control over who talks to whom
Identity-based policies Rules that survive pod IP changes
Namespace segmentation Isolation between environments and teams
Network observability Visibility of allowed and blocked flows
Node-to-node encryption Encrypted node traffic, when included in the architecture

In practice, the frontend talks to the API, the API talks to the database, and the frontend does not talk to the database. This reduces lateral movement if an application is compromised.

Policies are defined according to each cluster's isolation requirements — there is no single set imposed on every environment.

Managed lifecycle

Clusters run stable, supported Kubernetes versions. InteSys manages the platform lifecycle:

  • upgrade planning and supported-version tracking;
  • progressive worker node upgrades, with no environment downtime;
  • component compatibility and CNI updates;
  • workload validation after each update;
  • controlled node replacement;
  • cluster health monitoring.

The objective is to keep the platform current without transferring the operational complexity of that maintenance to the customer's team.

Division of responsibilities

Layer Owner
Datacenter, network and infrastructure InteSys (or the provider chosen for that region)
Worker operating system and hardening InteSys
Control plane, upgrades and CNI InteSys
Network policies, RBAC and namespaces InteSys, per customer requirements
Applications, images and dependencies Customer
Schema, data and business rules Customer

InteSys does not replace your development team

The most common model is InteSys taking on the platform, networking, infrastructure security and lifecycle, while the customer's team stays owner of the applications running on top of it.