mTLS by policy
Require mutual TLS between services as a rule rather than a manual config.
Operate
Service Mesh Governance
mTLS and traffic resilience as policy, rendered to your mesh
Define the service-to-service security and resilience you want, like mutual TLS, retries, timeouts, and circuit breaking, and render it to concrete mesh resources. The rules live as policy you own, and the platform turns them into the configuration your mesh runs.
- mTLS enforced as declared policy rather than per-service manual configuration
- Resilience rules consistent across every service from day one
- A tamper-evident record of every mesh policy change, ready for audit
The problem
Your service mesh config lives in raw YAML that each team authors by hand, so mTLS requirements and resilience rules drift per service and per team. When something breaks or an auditor asks which services enforce mutual TLS, you have no single answer, only a pile of configs you hope are up to date.
Without IntegraCI
- mTLS set per service in hand-authored mesh YAML
- Retry and timeout rules decided ad-hoc by each team
- No single view of what policy each service actually runs
- Mesh config changes with no record of who changed what or why
With IntegraCI
- mTLS required as declared policy, rendered to concrete mesh resources
- Resilience defaults defined once and applied consistently across services
- Preview the exact mesh config a policy produces before it reaches your cluster
- Mesh policy managed alongside your other platform controls in one place
What you get
Resilience defaults
Set retries, timeouts, and circuit breaking as policy for your services.
Rendered to the mesh
Policies render to concrete mesh resources you can preview before applying.
One place to manage
Manage mesh policy alongside the rest of your platform controls.
How it works
- 1
Define the policy
Declare the mTLS and traffic rules your services should follow.
- 2
Preview the render
See the concrete mesh resources the policy produces.
- 3
Apply to the mesh
The rendered configuration is applied to your service mesh.
How it stays governed
The same gates everyone passes, applied here.
Gated by policy
Every mTLS requirement and traffic resilience rule is declared as policy as code. The platform evaluates each service against those rules and renders only configuration that satisfies them, so a service cannot bypass mutual TLS or skip a required circuit-breaker through an ad-hoc override.
Recorded, tamper-evident
Each policy render and apply action writes once to a tamper-evident audit trail, recording which rule produced which mesh resource and when it was applied. If an auditor asks what policy a service ran at a given point in time, the record is already there.
A human in the loop
Before a rendered configuration is applied to the mesh, you can preview the exact resources it will produce. That preview step keeps a person in the path for any state-changing apply, so the mesh does not change without a deliberate decision.
Works with your stack
Connect the tools you already run.
Mesh governance sits at the intersection of infrastructure provisioning and security controls, targeting the policy layer above the mesh engine you already run.
- Apple
- Argo Project
- AWS
- Cloudflare
- CNCF
- Coder
- Crunchy Data
- Daytona
- Env0
- Keycloak
- MongoDB
- Okta
- OutSystems
- Pulumi
- Rancher
- Red Hat
- Sonatype
- +29 more
Who it’s for
Where teams reach for it.
Enforcing mTLS across a growing microservices fleet
As your service count grows, keeping every service on mutual TLS through manual config becomes impractical. You declare mTLS as a policy rule once and the platform renders the correct mesh resources for every service, removing the per-service repetition.
Giving every new service a resilience baseline on day one
A team shipping a new service should not have to research timeout and retry best practices from scratch. You define the resilience defaults that match your reliability standards and each new service inherits them through policy rather than through copy-pasted YAML.
Demonstrating mesh policy compliance to an auditor
When a security or compliance review asks which services enforce mutual TLS and what your circuit-breaking policy is, you point to the policy definitions and the tamper-evident record of every render and apply, rather than manually inspecting mesh config across the cluster.
Questions, answered.
Does IntegraCI replace my service mesh?
No. IntegraCI governs the mesh you already run. Your mesh engine keeps handling traffic. IntegraCI holds the policy rules, renders them to the concrete resources your mesh expects, and records every change.
How are the policy rules written?
Policies are defined as policy as code in the platform, using the same control surface you use for your other platform rules. You declare the mTLS and resilience behavior you want, and the platform handles translating that into mesh-specific configuration.
What happens if I want to preview a change before it applies?
The preview step is built into the workflow. After you define or update a policy, the platform renders the resulting mesh resources for you to inspect before anything is applied to the cluster. Nothing reaches the mesh until you decide to proceed.
Can teams still write their own mesh config directly?
Policy as code means the rules the platform manages are the authoritative source. Teams work with policies rather than authoring raw mesh YAML, which is how drift and ad-hoc exceptions get closed off. The rendered output is still inspectable and audited.
Put Service Mesh Governance on your stack.
Request a demo, or read the docs to see how it fits the tools you already run.