Aqua Security’s on-premises deployment isn’t just about keeping your secrets safe; it’s about a deliberate architectural choice that fundamentally alters how you manage container security.
Let’s see it in action. Imagine you’re running a Kubernetes cluster and want to secure your container images and running workloads.
# First, ensure you have Aqua's Helm repository added
helm repo add aquasec https://aquasec.github.io/helm-charts/
helm repo update
# Then, install Aqua Security. This command deploys the core Aqua components
# into your Kubernetes cluster. The `aqua-secrets` value is crucial for
# enabling advanced features that require encrypted data.
helm install aqua aquasec/aqua \
--namespace aqua-security \
--create-namespace \
--set secrets.enabled=true \
--set secrets.aqua.password="SuperSecretAquaPassword123!" \
--set deploy.gateway=true \
--set deploy.scanner=true \
--set deploy.admission=true \
--set deploy.audit=true \
--set deploy.console=true
This Helm command orchestrates the deployment of several key Aqua Security components:
- Aqua Gateway: Acts as the central communication hub for Aqua agents and the Aqua console. It’s the entry point for most Aqua operations.
- Aqua Scanner: Responsible for scanning container images for vulnerabilities and compliance issues.
- Aqua Admission Controller: Intercepts pod creation requests in Kubernetes and enforces security policies before containers can run.
- Aqua Audit: Collects and stores security-relevant events from your cluster.
- Aqua Console: The web-based user interface for managing Aqua Security.
The secrets.enabled=true and secrets.aqua.password are not just for show. On-premises deployments often deal with highly sensitive data, and Aqua uses these to encrypt internal communication and sensitive configuration details. The password you set here is used to encrypt the secrets within Aqua’s database, ensuring that even if the database is compromised, the encrypted data remains unreadable without this key.
The mental model for on-premises Aqua Security revolves around a distributed architecture where the Aqua Security platform components are deployed within your own infrastructure, typically on Kubernetes. You have full control over the deployment environment, network access, and data storage. This allows for strict air-gapped environments or compliance with data residency requirements.
The core problem Aqua solves is the lack of unified visibility and control over container security across the entire lifecycle – from build to runtime. Traditional security tools often struggle with the dynamic and ephemeral nature of containers. Aqua bridges this gap by providing:
- Vulnerability Management: Scanning images in your registries and during CI/CD pipelines.
- Compliance Auditing: Ensuring your containerized applications meet regulatory standards.
- Runtime Security: Detecting and preventing malicious activity within running containers.
- Network Segmentation: Controlling traffic between containers.
- Drift Detection: Identifying unauthorized changes to running workloads.
The levers you control are primarily around the deployment configuration and policy definition. You decide which components to deploy, where they run, and how they interact. For example, you might choose to deploy the Aqua Scanner on dedicated nodes for performance or scale the Admission Controller based on your cluster’s ingress traffic. The deploy.gateway, deploy.scanner, etc., flags in the Helm chart directly map to these decisions.
The on-premises model means you are responsible for the underlying infrastructure’s security, patching, and availability, but in return, you gain ultimate control and can meet the most stringent security and compliance mandates.
The next concept you’ll likely grapple with is integrating Aqua’s runtime security features with your existing CI/CD pipelines for a truly shift-left security posture.