Harden your deployment with isolation and network controls

Configure network isolation, endpoint authentication, and upload protection to harden a Kestra deployment.

By design, Kestra allows arbitrary HTTP calls and script execution. To prevent misuse of link-local metadata services (IMDS), isolate and block access at the network layer:

• Network ACLs or security groups: configure your VPC or firewall to deny all requests to link-local ranges (e.g., 169.254.169.254/32).
• Dedicated orchestration subnet: place Kestra workers in a private subnet with no route to management or metadata services.
• Egress proxy or NAT gateway filtering: route all outbound traffic through a proxy or gateway that can enforce allow-lists and block link-local IPs.

Host-level isolation

Running workflows in isolated environments reduces the impact of potentially malicious flows:

• Container sandboxes: launch each flow execution in its own container (for example, Docker or Kubernetes Pod) with minimal privileges.
• Ephemeral compute: use Kestra’s native Task Runners to auto-scale ephemeral compute nodes that are destroyed after each run, leaving no residual state.
• Minimum host permissions: grant only the OS-level rights required for the runtime; avoid mounting cloud credential files or granting host-level IAM roles directly.

Plugin and code validation

• Plugin configuration: use Kestra’s plugin architecture, including Plugin Versioning, to control which plugins are allowed and which should be prohibited.
• CI/CD validation: add a Flow Validation step in your CI/CD pipeline to scan task definitions for disallowed patterns (e.g., 169.254.169.254) and block merging if detected.
• Java Security (EE): Enterprise Edition users can define security policies to restrict access to untrusted files, plugins, or network resources.

Credential initialization

On Enterprise Edition, use OIDC/SSO or LDAP instead of Basic Authentication. These integrate with your existing identity provider, support MFA, and remove the risk of locally managed credentials.

If you use Basic Authentication on OSS or EE:

kestra:
  server:
    basic-auth:
      username: admin@kestra.io
      password: "{{ your-strong-password }}"

Management endpoint access

Kestra exposes internal endpoints on a separate management port (default 8081). These include health checks, runtime log level changes (/loggers), metrics (/metrics), and an environment inspection endpoint (/env) that can expose configuration values. This port is unauthenticated by default.

The primary protection is network isolation: do not expose port 8081 outside the internal network. Firewall or security-group rules should restrict access to the management port to trusted internal hosts only (monitoring agents, load balancer health checkers, operations tooling).

If network isolation is not sufficient, you can add Basic Auth to the management port and optionally move it to a non-default port by configuring endpoints.all in your application.yml:

endpoints:
  all:
    port: 8084   # move away from the default 8081
    basic-auth:
      username: <management-username>
      password: <strong-password>

When basic-auth credentials are present, Kestra’s management endpoint filter requires Basic Auth on every request to that port.

You can also disable individual endpoints you do not need:

endpoints:
  env:
    enabled: false   # disables /env, which can expose config values

See Kestra endpoints for the full list of what is exposed on the management port.

Documentation and audit

• User guidance: update onboarding materials and runbooks to highlight metadata-blocking best practices when deploying a new Kestra environment.
• Periodic review: include network and host configuration checks in your security audit cycle to verify link-local ranges remain blocked.