What are the exact Helm install steps to deploy Operant on EKS, and what permissions does it need?
AI Application Security

What are the exact Helm install steps to deploy Operant on EKS, and what permissions does it need?

12 min read

Most teams land on this question in the last mile before rollout: you’ve validated Operant as your Runtime AI Application Defense Platform, you’re running on EKS, and now you want the exact Helm install steps and a precise view of what permissions Operant needs inside your cluster.

This guide walks through:

  • A concrete, copy-pasteable Helm install flow for EKS
  • How to wire in AWS/IAM and Kubernetes RBAC cleanly
  • What permissions Operant needs and why (in plain threat-model terms)

It reflects how we actually deploy in production: single step Helm install, zero instrumentation, zero integrations, works in minutes—without handing a security tool blind “cluster-admin forever” access.

Pre‑requisites for deploying Operant on EKS

Before you run the Helm command, make sure you have:

  • An EKS cluster (any standard AWS EKS version Operant supports)
  • kubectl configured and pointing to your EKS cluster 
    aws eks update-kubeconfig --name <EKS_CLUSTER_NAME> --region <AWS_REGION>
  • Helm 3+ installed on your workstation or CI runner
  • Permissions to:
    • Create namespaces
    • Create cluster‑wide RBAC (ClusterRoles / ClusterRoleBindings)
    • Create CustomResourceDefinitions (CRDs)
    • Create mutating/validating webhooks and PodSecurityPolicy / PodSecurityAdmission objects if used in your cluster

If you’re locked down by a platform team, you can run these as a one-time bootstrap with an elevated role and then delegate day‑2 control to a narrower RBAC profile.

At-a-glance Helm install flow on EKS

Here’s the minimal high‑level flow you’ll follow:

  1. Add the Operant Helm repo
  2. Create an operant namespace (or your preferred name)
  3. (Optional but recommended) Create an IAM policy & IRSA for Operant
  4. Create a values file to configure cluster name, environment, and auth
  5. Install Operant using a single Helm command
  6. Verify pods, webhooks, and CRDs are healthy

The rest of this article unpacks each step with example YAML and CLI commands.

Step 1 – Add the Operant Helm repo

Run this from a machine with Helm configured:

helm repo add operant https://charts.operant.ai
helm repo update

(If your Operant team or account rep gave you a private chart URL, use that instead of the placeholder above.)

Step 2 – Create the Operant namespace

kubectl create namespace operant-runtime

You can choose a different name, but sticking to operant-runtime helps keep logs, policies, and RBAC consistent with default examples.

Step 3 – Set up IAM & IRSA (recommended for EKS)

On EKS, you want Operant to use IAM roles for service accounts (IRSA) instead of embedding static credentials. This is where we align cluster‑internal enforcement with AWS‑native identity controls.

3.1 Create an IAM policy for Operant

This policy should cover only what Operant actually needs from AWS. At a minimum, you’ll typically grant read access to:

  • EC2 / EKS metadata (for node / cluster context)
  • CloudWatch / CloudTrail (if you integrate external signals)
  • SSM Parameter Store / Secrets Manager (if you choose to store keys there)

A starting example:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "OperantDescribeInfra",
      "Effect": "Allow",
      "Action": [
        "eks:DescribeCluster",
        "ec2:DescribeInstances",
        "ec2:DescribeVpcs",
        "ec2:DescribeSubnets"
      ],
      "Resource": "*"
    },
    {
      "Sid": "OperantReadObservability",
      "Effect": "Allow",
      "Action": [
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams",
        "logs:GetLogEvents",
        "cloudtrail:LookupEvents"
      ],
      "Resource": "*"
    }
  ]
}

Create the policy:

aws iam create-policy \
  --policy-name OperantRuntimePolicy \
  --policy-document file://operant-iam-policy.json

(Your Operant deployment guide may include a more precise, scoped policy for your use case—use that if provided.)

3.2 Create an IAM role for service account (IRSA)

Assuming your EKS OIDC provider is already set up:

AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
OIDC_PROVIDER=$(aws eks describe-cluster \
  --name <EKS_CLUSTER_NAME> \
  --query "cluster.identity.oidc.issuer" \
  --output text | sed -e "s/^https:\/\///")

aws iam create-role \
  --role-name OperantRuntimeRole \
  --assume-role-policy-document "{
    \"Version\": \"2012-10-17\",
    \"Statement\": [
      {
        \"Effect\": \"Allow\",
        \"Principal\": {
          \"Federated\": \"arn:aws:iam::${AWS_ACCOUNT_ID}:oidc-provider/${OIDC_PROVIDER}\"
        },
        \"Action\": \"sts:AssumeRoleWithWebIdentity\",
        \"Condition\": {
          \"StringEquals\": {
            \"${OIDC_PROVIDER}:sub\": \"system:serviceaccount:operant-runtime:operant-runtime\"
          }
        }
      }
    ]
  }"

Attach the policy:

aws iam attach-role-policy \
  --role-name OperantRuntimeRole \
  --policy-arn arn:aws:iam::${AWS_ACCOUNT_ID}:policy/OperantRuntimePolicy

You’ll reference this role in the service account via eks.amazonaws.com/role-arn.

Step 4 – Create the Operant service account with IRSA

Create a service account manifest that Operant will use:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: operant-runtime
  namespace: operant-runtime
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::<AWS_ACCOUNT_ID>:role/OperantRuntimeRole

Apply it:

kubectl apply -f operant-serviceaccount.yaml

This binds your EKS identity plane to Operant’s runtime enforcement components with least privilege.

Step 5 – Define your Helm values for Operant on EKS

Create a operant-values.yaml file. This is where you wire cluster naming, service account, ingress, and optional features like MCP and API protection.

A representative example:

global:
  clusterName: "<EKS_CLUSTER_NAME>"
  environment: "prod"        # or dev / staging
  cloudProvider: "aws"

operant:
  serviceAccount:
    create: false            # we created it manually above
    name: operant-runtime

  # Enable runtime AI application defense
  aiDefense:
    enabled: true
    # If you’re securing MCP/agents, you’d add MCP-specific settings here
    # mcp:
    #   gatewayEnabled: true

  # API & cloud protection
  apiProtection:
    enabled: true

  # K8s-native controls
  k8sSecurity:
    enabled: true

  # Ingress / access to Operant UI & APIs
  ingress:
    enabled: true
    className: "alb"         # or nginx, depending on your setup
    hosts:
      - host: "operant.<your-domain>"
        paths:
          - path: /
            pathType: Prefix

  # TLS (example – adapt to your cluster)
  tls:
    enabled: true
    secretName: operant-tls

  # Resource requests/limits – tune for your clusters
  resources:
    limits:
      cpu: "2"
      memory: "4Gi"
    requests:
      cpu: "500m"
      memory: "1Gi"

If your Operant team has given you a baseline values file for your environment, start from that and layer in IRSA + ingress specifics.

Step 6 – Install Operant via Helm on EKS

With the repo, namespace, service account, and values file in place, install:

helm install operant-runtime operant/operant \
  --namespace operant-runtime \
  --values operant-values.yaml

This is the “single step Helm install” in practice: one command, no code changes, no app instrumentation. Operant attaches at the runtime layer—Kubernetes, APIs, MCP/agents, and inline traffic.

To upgrade later:

helm upgrade operant-runtime operant/operant \
  --namespace operant-runtime \
  --values operant-values.yaml

Step 7 – Validate the deployment on EKS

Verify pods:

kubectl get pods -n operant-runtime

You should see core components in Running or Completed state (names may vary slightly by version), e.g.:

  • operant-controller-*
  • operant-runtime-*
  • operant-ui-*
  • operant-webhook-*

Check CRDs:

kubectl get crds | grep operant

You should see CRDs for policies, zones, and runtime objects that power 3D Runtime Defense (Discovery, Detection, Defense).

Verify webhooks (for inline enforcement):

kubectl get mutatingwebhookconfigurations,validatingwebhookconfigurations \
  | grep -i operant

If you have strict network policies or custom CNI, make sure the Operant namespace can reach the Kubernetes API and internal services it needs for discovery and enforcement.

What permissions does Operant need on EKS?

When you deploy a Runtime AI Application Defense Platform on EKS, you’re giving it authority inside the “cloud within the cloud”—your internal APIs, services, and identities. Operant is designed to use that authority to detect and block real threats (prompt injection, data exfiltration, east–west attacks, rogue agents) while staying auditable and scoped.

Broadly, Operant uses four buckets of permissions:

  1. Kubernetes cluster‑level permissions (CRDs, webhooks, RBAC)
  2. Kubernetes resource‑level read access (for discovery/blueprints)
  3. Kubernetes runtime controls (for inline blocking/segmentation)
  4. AWS IAM permissions (optional, for cloud‑context integration)

Let’s break each down.

1. Cluster‑level Kubernetes permissions

To deliver 3D Runtime Defense, Operant needs the ability to extend the Kubernetes control plane:

  • Create / manage CRDs

    • For Operant policy definitions, trust zones, runtime objects, findings, etc.
    • This is how you express “block data exfiltration from agent X to API Y” as an object the cluster understands.

  • Create mutating / validating admission webhooks

    • To intercept pod / workload creation and enforce guardrails:
      • Block workloads that violate K8s Identity and Entitlement rules
      • Enforce trust zones for services and agents
      • Auto‑inject runtime controls where needed
    • This is how Operant works inline rather than as a passive observer.

  • Read cluster‑wide resources

    • nodes, namespaces, deployments, statefulsets, daemonsets, services, ingresses, networkpolicies
    • Needed to build the “live API blueprint” and dependency graph that underpins detection and enforcement.

In RBAC terms, this often looks like a ClusterRole with:

  • get, list, watch on core and apps APIs
  • create, update, patch, delete on Operant CRDs
  • create, update, patch on webhooks and related admission resources

2. Resource‑level read access for runtime discovery

Operant’s Discovery layer needs read‑only visibility into:

  • K8s objects: Pods, Services, Deployments, ReplicaSets, Jobs, CronJobs
  • API objects: Ingresses, Service definitions, Gateway/Route resources in service meshes
  • Config: ConfigMaps, Secrets (names / metadata; data access is controlled and audited)

This allows Operant to:

  • Discover ghost and zombie APIs that still accept traffic
  • Map live MCP connections, AI agents, and internal APIs
  • Correlate identity (service accounts, roles) with active traffic

Typical RBAC permissions here:

  • get, list, watch on the above resources across namespaces
  • Optional: restricted get on Secrets data if you choose features that depend on it
    • Many customers prefer “metadata‑only” secret visibility—Operant supports deploying with more restrictive controls if that’s your policy.

3. Runtime enforcement permissions (block, rate‑limit, segment)

This is where Operant moves beyond dashboards and actually defends your cluster and AI workloads.

Operant needs permissions to:

  • Apply / modify NetworkPolicies or equivalent constructs

    • For microsegmentation: API‑to‑API and agent‑to‑tool trust zones
    • To block east–west lateral movement and “Shadow Escape” paths

  • Patch workload specs (where configured)

    • To inject sidecars or agents (if used)
    • To apply security annotations, environment vars, or runtime policies
    • This is done via admission webhooks + RBAC, and scoped to the namespaces/workloads you select.

  • Manage Operant policy CRDs

    • To translate high‑level governance (“agents may not call internal billing APIs”) into concrete enforcement.

  • Inline auto‑redaction and data controls

    • When protecting AI/agent flows, Operant can redact sensitive data inline—as it flows through APIs and MCP toolchains.
    • Runtime enforcement needs the authority to intercept and reshape traffic in these paths (via the runtime components you deploy).

RBAC manifestations:

  • create, update, patch, delete on:
    • networkpolicies (or equivalent mesh policies)
    • Operant CRDs (policy, trust zones, enforcement rules)
  • patch on workload resources in selected namespaces (if you enable injection/auto‑hardening)

You can scope this down by namespace to align with your environment boundaries (e.g., prod-apps, ai-agents, internal-apis).

4. AWS IAM permissions (cloud‑context and observability)

Operant “starts working without any integrations,” but on EKS you often want cloud context for:

  • Mapping nodes to AWS instances and subnets
  • Correlating K8s identities with IAM roles and external services
  • Anchoring runtime events to CloudWatch/CloudTrail for unified auditing

That’s the role of the IAM policy/IRSA in Step 3. Typical permissions include:

  • eks:DescribeCluster – know which cluster we’re protecting
  • ec2:Describe* – tie nodes and IPs back to AWS networks
  • logs:Describe*, logs:GetLogEvents – if you enable log‑level correlation
  • Optional: access to Secrets Manager / Parameter Store if you store Operant keys or integration secrets there

You can keep this policy read‑mostly and audit‑friendly. Inline enforcement happens inside the cluster via Kubernetes-native controls, not via privileged AWS APIs.

Example Kubernetes RBAC for Operant (cluster‑scoped)

A simplified ClusterRole to illustrate the pattern (you should use the official chart’s RBAC, not copy this verbatim into production):

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: operant-runtime
rules:
  - apiGroups: [""]
    resources:
      - pods
      - services
      - endpoints
      - namespaces
      - nodes
      - configmaps
      - secrets
    verbs: ["get", "list", "watch"]
  - apiGroups: ["apps"]
    resources:
      - deployments
      - daemonsets
      - statefulsets
      - replicasets
    verbs: ["get", "list", "watch", "patch"]
  - apiGroups: ["networking.k8s.io"]
    resources:
      - networkpolicies
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  - apiGroups: ["admissionregistration.k8s.io"]
    resources:
      - mutatingwebhookconfigurations
      - validatingwebhookconfigurations
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  - apiGroups: ["operant.ai"]   # example API group for Operant CRDs
    resources: ["*"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

Bound to the Operant service account:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: operant-runtime-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: operant-runtime
subjects:
  - kind: ServiceAccount
    name: operant-runtime
    namespace: operant-runtime

The official Helm chart will create the necessary RBAC objects for you; this is just to make the permission model explicit.

How to think about Operant permissions in your threat model

From an operator’s point of view, here’s the right mental model:

  • Operant sits inside your application perimeter—inside EKS—where the real attacks against AI apps and APIs land: authenticated sessions, east–west hops, agent toolchains, MCP tools.
  • To defend that surface, it needs:
    • Read access to build a real‑time graph of workloads, APIs, agents, and identities
    • Control‑plane hooks (webhooks, CRDs) to express policies the cluster can enforce
    • Runtime controls (network policies, traffic interception, auto‑redaction) to block, rate‑limit, and segment live flows
  • It does not need blanket write access to your AWS account or carte‑blanche credentials to your apps; IAM is scoped, and enforcement happens primarily with Kubernetes‑native mechanisms.

If you’ve been burned by “observability tools” that collected everything and protected nothing, this is the opposite: Operant’s permissions converge on one goal—inline enforcement that actually blocks prompt injection, jailbreaks, tool poisoning, and data exfiltration in your EKS‑hosted AI and cloud apps.

Summary: exact Helm steps + permissions, in one place

To deploy Operant on EKS with Helm:

  1. Configure kubectl and Helm against your EKS cluster.
  2. helm repo add operant https://charts.operant.ai && helm repo update
  3. kubectl create namespace operant-runtime
  4. Create an IAM policy + IRSA role and a service account annotated with eks.amazonaws.com/role-arn.
  5. Create operant-values.yaml with cluster name, environment, service account, ingress, and feature toggles.
  6. Run: 
    helm install operant-runtime operant/operant \
  --namespace operant-runtime \
  --values operant-values.yaml
  7. Verify pods, CRDs, and webhooks are healthy in operant-runtime.

From a permissions standpoint, Operant needs:

  • Kubernetes cluster‑level rights to install CRDs and admission webhooks
  • Read‑mostly visibility across workloads, services, and namespaces
  • Scoped write rights to network policies, Operant CRDs, and optional workload patches for enforcement
  • Optional, least‑privilege IAM via IRSA for AWS context and integrations

If you want to walk through these steps against your live EKS cluster and see Operant start blocking real traffic paths in minutes, you can schedule a working session with the team:

Get Started

Back to AI Application Security

Keep Reading

More from AI Application Security

Operant security review: where can I find SOC 2 Type II info and details on data flow/what gets logged?

Read more

How do we send Operant detections to Datadog or Grafana for alerting and incident response workflows?

Read more

How do we set up Operant MCP Gateway with an MCP catalog/registry and allowlist/denylist for servers and tools?

Read more