Skip to main content
This page summarizes the security posture of a Flyte deployment and points to the relevant detailed guides.

​
Non-root containers

All Flyte core components (FlyteAdmin, FlytePropeller, DataCatalog, FlyteConsole) run as non-root users. A dedicated system user and group are created in each component’s Dockerfile and specified via the Kubernetes securityContext. Running as non-root is considered best practice because:
  • It prevents malicious code from using root host permissions
  • It is required on platforms such as OpenShift
  • It reduces blast radius in the event of a container escape
Certain init containers still require root permissions. For example, the check-db-ready init container in FlyteAdmin runs as root because it cannot resolve DNS without read access to /etc/hosts. This is a known limitation that the Flyte team is tracking.

​
Security context example (FlyteAdmin)

The Flyte Helm chart configures the following security context for FlyteAdmin: 
securityContext:
  runAsUser: 1001
  runAsGroup: 1001
  fsGroup: 1001
  runAsNonRoot: true
To enforce non-root execution for task pods as well, add a security context to your default PodTemplate: 
apiVersion: v1
kind: PodTemplate
metadata:
  name: flyte-template
  namespace: flyte
template:
  spec:
    securityContext:
      runAsNonRoot: true
      runAsUser: 1000
    containers:
      - name: default
        image: docker.io/rwgrim/docker-noop

​
TLS and HTTPS

FlyteAdmin exposes both an HTTP and a gRPC endpoint. In production:
  • Terminate TLS at the Ingress layer (ALB, NGINX, or GKE Ingress)
  • Use a CA-issued certificate (self-signed certificates are not supported by flytectl for OAuth flows)
  • Configure HTTPS redirect in your Ingress annotations
flytectl requires a CA-signed SSL certificate for OAuth to work. Using a self-signed certificate causes the error: certificate is not standards compliant.

​
Authentication

Flyte supports OAuth 2.0 and OpenID Connect for authenticating both human users (via the browser) and service accounts (via client credentials). See the authentication guide for setup instructions. In summary:
  • UI access uses OIDC (browser redirect to your IdP)
  • flytectl and pyflyte use PKCE or client credentials
  • FlytePropeller authenticates to FlyteAdmin using a shared client secret

​
Secrets management

Flyte provides a secrets injection framework that delivers secrets to task pods at runtime without exposing them in workflow code or task specs. See the secrets guide for details.

​
RBAC and access control

Flyte’s access control model is based on projects and domains. See the RBAC guide for details on mapping OIDC claims to Flyte roles.

​
Network policies

Flyte services communicate over the following ports:
SourceDestinationPortProtocol
FlyteConsole browserFlyteAdmin443HTTPS
flytectl / pyflyteFlyteAdmin443gRPC-TLS
FlytePropellerFlyteAdmin81gRPC (in-cluster)
FlytePropellerDataCatalog8081gRPC (in-cluster)
FlyteAdminPostgreSQL5432TCP
Task podsObject store443HTTPS
Recommended Kubernetes NetworkPolicies: 
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: flyte-admin-ingress
  namespace: flyte
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: flyteadmin
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app.kubernetes.io/name: flytepropeller
      ports:
        - port: 81
    - from: []     # Allow from all (for Ingress controller)
      ports:
        - port: 8088
        - port: 8089

​
Cross-origin resource sharing (CORS)

When FlyteAdmin and FlyteConsole run on different domains, configure CORS: 
configmap:
  adminServer:
    server:
      security:
        allowCors: true
        allowedOrigins:
          - 'https://console.flyte.example.com'
        allowedHeaders:
          - 'Content-Type'
Then restart FlyteConsole to set ADMIN_API_URL: 
kubectl edit deployment flyteconsole -n flyte
# Add env:
# - name: ADMIN_API_URL
#   value: https://admin.flyte.example.com

kubectl rollout restart deployment/flyteconsole -n flyte
kubectl rollout restart deployment/flyteadmin -n flyte

​
Audit logging

All FlyteAdmin API calls are logged. To increase verbosity and capture audit events, set the log level: 
configuration:
  logging:
    level: 5
For structured audit logs, forward container stdout logs to your SIEM (CloudWatch, Stackdriver, Splunk) using your cluster’s log aggregation pipeline.

​
Security checklist

  • TLS certificate issued by a trusted CA is configured at the Ingress
  • Authentication is enabled (auth.enabled: true)
  • Database connection uses sslmode=require or stronger
  • MinIO (if used) is not publicly accessible
  • Kubernetes NetworkPolicies restrict traffic between namespaces
  • Task pods run as non-root
  • Secrets are managed via the Flyte secrets injection framework, not environment variables
  • RBAC is configured to restrict project access to appropriate teams
  • Container images are scanned for vulnerabilities in CI

Build docs developers (and LLMs) love

Get started for freeTalk to us