Wiz for Enterprise Cloud Security: Architecture, Deployment, and Operational Guide

Overview

Wiz is an agentless CNAPP platform focused on cloud security posture management, vulnerability management, identity risk, exposed secrets, malware detection, and attack path analysis across AWS, Azure, GCP, Kubernetes, and major container registries. Enterprises use Wiz because it builds a unified graph of cloud assets and relationships, helping teams prioritize risks based on blast radius, exploitability, internet exposure, and privilege paths rather than isolated alerts.

In practice, Wiz is commonly adopted by security architecture, cloud platform, and DevSecOps teams to answer questions such as:

• Which internet-facing workloads also have critical CVEs and access to sensitive data?
• Which identities can laterally move to production subscriptions or accounts?
• Which misconfigurations violate CIS, NIST, PCI DSS, ISO 27001, or internal guardrails?

Architecture

Wiz uses an API-based, read-only integration model for most discovery and posture capabilities, reducing operational friction compared with agent-heavy tools. Core architectural elements include:

• Wiz SaaS control plane: Stores normalized metadata, builds the security graph, runs analytics, and presents dashboards, issues, and policies.
• Cloud connectors: Cross-account or cross-subscription roles/service principals that allow Wiz to ingest configuration, identity, network, and workload metadata.
• Optional runtime sensors/integrations: Used for deeper container, Kubernetes, or workload context depending on enabled modules.
• Integrations layer: SIEM, SOAR, ticketing, Slack, and CI/CD systems for workflow automation.

Data flow

1. Cloud admins create least-privilege roles or service principals in AWS, Azure, or GCP.
2. Wiz assumes or uses those identities to collect metadata from APIs such as AWS Organizations, EC2, IAM, EKS, Azure Resource Graph, Microsoft Graph, GCP Asset Inventory, and Kubernetes APIs.
3. Wiz correlates assets into a graph and evaluates policies, attack paths, vulnerabilities, and compliance controls.
4. Findings are pushed to downstream systems such as Jira, ServiceNow, Splunk, or Microsoft Sentinel.

Implementation Guide

A common enterprise rollout starts with AWS, then expands to Azure, GCP, Kubernetes, and CI/CD.

1. Prepare AWS onboarding role using CloudFormation or Terraform. Example with AWS CLI:

aws cloudformation deploy \
  --stack-name wiz-readonly \
  --template-file wiz-aws-readonly.yaml \
  --capabilities CAPABILITY_NAMED_IAM \
  --parameter-overrides ExternalId=wiz-prod-123456 RoleName=WizReadOnlyRole

1. Verify trust policy and permissions boundary before enabling organization-wide access:

aws iam get-role --role-name WizReadOnlyRole
aws organizations describe-organization

1. Create Azure app registration/service principal for subscription discovery:

az ad app create --display-name wiz-reader-app
az ad sp create --id $(az ad app list --display-name wiz-reader-app --query "[0].appId" -o tsv)
az role assignment create --assignee <appId> --role Reader --scope /subscriptions/<subscription-id>

1. Connect Kubernetes clusters by granting read-only access to workload and RBAC metadata.
2. Enable integrations for ticketing and SIEM, then map severity to operational queues.
3. Tune policies by business unit, environment, and internet exposure; suppress approved exceptions with expiration dates.
4. Validate findings against a sample of known risky assets before broad executive reporting.

Code Examples

AWS IAM trust policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::123456789012:root"},
      "Action": "sts:AssumeRole",
      "Condition": {"StringEquals": {"sts:ExternalId": "wiz-prod-123456"}}
    }
  ]
}

Kubernetes read-only RBAC

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: wiz-readonly
rules:
- apiGroups: [""]
  resources: ["pods", "services", "nodes", "namespaces", "configmaps"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["deployments", "daemonsets", "statefulsets", "replicasets"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["roles", "rolebindings", "clusterroles", "clusterrolebindings"]
  verbs: ["get", "list", "watch"]

Terraform AWS onboarding role

resource "aws_iam_role" "wiz_readonly" {
  name = "WizReadOnlyRole"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Principal = { AWS = "arn:aws:iam::123456789012:root" }
      Action = "sts:AssumeRole"
      Condition = { StringEquals = { "sts:ExternalId" = "wiz-prod-123456" } }
    }]
  })
}

Security Hardening

• Enforce least privilege for every cloud connector; avoid broad AdministratorAccess during onboarding.
• Require external IDs for cross-account AWS roles to reduce confused-deputy risk.
• Scope Azure roles to Reader and specific subscriptions or management groups where possible.
• Protect access to Wiz with SSO via SAML/OIDC, MFA, and role-based access control.
• Send audit events to a SIEM and review admin actions such as connector changes, policy edits, and suppressions.
• Classify sensitive projects and use segregated workspaces or access boundaries for regulated environments.
• Review encryption commitments in the SaaS service and validate key management, data residency, and retention against policy.

Comparison

Troubleshooting

Error 1: AWS role assumption failure

Log sample:

AccessDenied: User: arn:aws:sts::123456789012:assumed-role/WizReadOnlyRole/session is not authorized to perform: organizations:DescribeOrganization

Fix: Add the missing Organizations read permission or scope onboarding to account-level discovery only.

Error 2: Azure consent or RBAC issue

Log sample:

AuthorizationFailed: The client '8f3d2b1a-2b6a-4d91-a4f1-1d0f0f5c1111' with object id '8f3d2b1a-2b6a-4d91-a4f1-1d0f0f5c1111' does not have authorization to perform action 'Microsoft.ResourceGraph/resources/read'

Fix: Assign the Reader role at the correct subscription or management group and confirm admin consent for required Graph permissions.

Error 3: Kubernetes API access denied

Log sample:

E0711 09:14:22.184321 1 reflector.go:138] Failed to watch *v1.Pod: pods is forbidden: User "system:serviceaccount:wiz:wiz-reader" cannot list resource "pods" in API group "" at the cluster scope

Fix: Bind the service account to the wiz-readonly ClusterRole and verify namespace and cluster-scope permissions.

Best Practices

Do

• Start with one production and one non-production landing zone to validate policy noise.
• Map findings to business owners using tags, subscriptions, folders, or account metadata.
• Integrate with Jira or ServiceNow and auto-route critical internet-exposed issues.
• Use exception expiration dates and require approval for suppressions.

Don't

• Do not grant broad write permissions just to simplify onboarding.
• Do not send all findings to one queue; separate posture drift, vulnerabilities, and identity risks.
• Do not measure success by raw alert counts; track time to remediate toxic combinations and reduction in exposed critical assets.