The Panoptica controller is deployed as a single pod in any Kubernetes cluster, including managed environments such as GKE. From there, it can apply Panoptica workload management methods on the entire cluster.
As part of the deployment, an extended version of Istio service mesh is also deployed as a pod in the cluster.

As soon as the controller is deployed on the cluster, you will gain the following benefits:

• visibility about what workloads (microservices, containers, etc.) are running on the cluster, and the communications between them, and with the external world.
• control over which workloads run on the cluster, and with whom they can communicate, by defining a few simple Panoptica runtime policy rules.
• implicit, automatic scalability as you grow the cluster to production scales, without having to change the Panoptica controller or policies.
• the ability to apply Panoptica runtime policies on workloads running on multiple clusters.

📘

Prerequisites for the cluster

• Kubernetes 1.23 or later
• Cluster should have at least three nodes
• K8s CLI should be installed on the machine or VM from which the deployment is run, with connectivity to the cluster (to run kubectl commands)
• DNS resolution and external access to these domains, on port 443:
  • Panoptica platform: appsecurity.cisco.com (34.74.85.197)
  • GCP Container Registry (if not using internal registry): gcr.io/eticloud/k8sec
  • Grype database: toolbox-data.anchore.io

Configuration	Resources (Memory & CPU)
Panoptica without Istio	5GB memory, 1.2 vCPU cores (total, for all nodes)
Panoptica including Istio control plane	3.5 GB memory, 7 vCPU cores (total, for all nodes)
Panoptica including Istio control plane and API tracing	15 GB memory, 10 vCPU cores (total, for all nodes

📘

API Security Requirements

API discovery and the API security features need to observe real API traffic. To achieve this, Panoptica's API Security has a couple more prerequisites:

1. Panoptica requires persistent storage for API Security, which means it needs to satisfy a Persistent Volume Claim of 100 MB, with Read/Write access mode.
   See Persistent Volumes at kubernetes.io for details.
2. If you're enabling external API gateways—to supply external traces to the cluster controller—you'll need an external load balancer.
   See Create an External Load Balancer at kubernetes.io for details.

High Availability

The Panoptica controller on the cluster provides High Availability to dynamically meet the needs of your workloads as they run on the cluster. The controller will replicate automatically to create additional controllers, to meet dynamic load conditions from your workloads, and decrease as load declines.

Deploy the Panoptica controller

If you haven't already signed up for Panoptica's free tier, you first need to create an account at panoptica.app. Click Login, then Sign Up, and choose how you wish to authenticate.

To connect your Kubernetes environment to Panoptica, first define your cluster in the Panoptica platform, then install our controller in your cluster. There are three (3) methods you can use to deploy the Panoptica controller:

• Deploy using Console UI
• Deploy using Helm
• Deploy using Terraform

Uninstall the Panoptica controller

If you no longer require Panoptica's services, see Uninstalling Panoptica.