Video summary

Cigna enhances Red Hat OpenShift Security with Red Hat Advanced Cluster Security & GitOps

Main summary

Key takeaways

Technology

Purpose / Challenge at Cigna

Cigna needed to rapidly improve OpenShift security posture across a large environment while maintaining agility to new threats. Their desired end state was to:

  • Manage and monitor security policies from a single “source of truth”
  • Consistently distribute and maintain those policies across the OpenShift environment

Scale of Cigna’s OpenShift Environment

  • ~725 nodes across production and non-production
  • ~23,000+ CPU cores
  • ~124,000 GB memory
  • Expected ~100% growth over the next year as more workloads move to OpenShift

Limitations of Cigna’s Earlier Vulnerability Workflow

Cigna previously used:

  • Clear security scanner data
  • A homegrown deployment compliance tool: “endorser”

How “endorser” worked in the deployment pipeline

Endorser validated images during deployment by:

  • Querying Quay (and “Claire”/scanner data)
  • Enforcing rules such as:
    • No critical/high vulnerabilities
  • Requiring images to be signed only after passing checks

Why the workflow broke down as scale increased

As more applications reached “maintenance mode,” newly discovered vulnerabilities in already-deployed images were not remediated quickly.

They also needed answers to questions like:

  • How to detect new vulnerabilities after deployment
  • Which deployed instances are affected by newly flagged images
  • How to ensure developers follow best practices and required security standards
  • How to detect network anomalies tied to suspicious activity

Why Red Hat Advanced Cluster Security (ACS)

Cigna selected Red Hat Advanced Cluster Security, formerly StackRocks.

ACS enables:

  • DevSecOps / shift-left security integrated into OpenShift/Kubernetes APIs
  • Runtime security coverage

ACS Capabilities (Six Core Security Use Cases)

  1. Vulnerability management Identify image sources, where images are in use, their components, and how vulnerabilities impact components—presented to developers for remediation.

  2. Configuration management Assess security-relevant configuration such as:

    • Network exposure
    • Storage use
    • Secrets
    • Service account privileges
  3. Risk profiling Correlate vulnerabilities, privileges, and network exposure to estimate attack likelihood and blast radius (e.g., foothold/lateral movement).

  4. Network segmentation “Container firewalling” via Kubernetes NetworkPolicies to restrict access, contain attackers, and support compliance needs.

  5. Compliance Evaluate application stance against industry/regulatory standards.

  6. Runtime protection Detect suspicious behavior by examining network and container/process activity, helping identify threat-actor activity even after deployment.

ACS Architecture

Central control plane (“single pane of glass” + policy engine)

  • One UI for operators/security teams
  • One policy engine to ensure consistent policy rollout across clusters

Secured clusters

Secured clusters run:

  • Collector/sensor components
  • An admission controller

These are built as Kubernetes-native workloads, leveraging Deployments, DaemonSets, HPA, and declarative configuration.

Integration emphasis

ACS integrates with:

  • Image registries
  • CI/CD systems
  • Security event management tools

Integrations are configured centrally using an API-based approach to support consistency and automation.

Cigna’s Accelerated Rollout (GitOps + Argo CD + OpenShift)

While the original rollout plan was gradual, it accelerated after the log4j exploit disclosure.

Cigna used Argo CD GitOps to deploy ACS at scale quickly.

Deployment structure in Argo

ACS deployment was broken into two Argo applications (each based on Helm charts):

  • One for ACS Central (central scanner/database)
  • One for secured clusters (sensor/collector/admission controller)

Central and secured clusters were mapped using cluster-specific Helm value files.

Policy/configuration as code

Central configuration was applied through:

  • Helm + jobs (so setup could be driven from GitOps rather than manual steps)

Jobs handled tasks such as:

  • Console authentication
  • Third-party integrations
  • Reinforcement/alerting policies

Automated cluster enrollment

Cigna used a script to automate enrollment:

  • Request cluster-specific API keys from Central
  • Generate init configuration using Rock CTL
  • Apply resulting YAML secrets to enroll cluster sensors back to Central

They also downloaded the Rock CTL version matching Central to keep tooling consistent.

Challenges Encountered (and How They Were Addressed)

  • OpenShift SCC conflicts

    • Fixed by operator changes
  • Deployment in non-standard namespaces

    • Improved operator flexibility based on customer feedback
  • Quay integration issues at Cigna’s scale

    • Quay connections were not properly handled, causing overload
    • Root cause identified and fixed, including improved correct handling/scoping for Quay tokens
  • Memory scaling concerns

    • ACS memory growth tied to tracking unique images and their vulnerabilities at large scale
    • Planned improvements to reduce the need for continual scaling (memory reclamation)

Measured Value / Outcomes for Cigna

  • Alerting on vulnerable deployments (not just images in registries) and notifying dev teams for remediation
  • Earlier detection during development:
    • Using Rock CTL with CI/CD pipelines to validate configuration/image specs against ACS policies before deployment
  • Runtime detection of network/execution anomalies
    • Helps identify suspicious behavior such as developers/attackers logging into containers and executing commands in what should be immutable images

Roadmap / Future Direction

  • More integrations and automation
  • Improving ACS GitOps “policy as code” capabilities
  • Enhancements aligned to secure supply chain themes
  • Upstream open-source project:
    • StackRocks name/logo preserved
    • Community: stackrocks.io
    • Release expected soon

Main Speakers / Sources

  • James Walton — Associate Principal Cloud Solution Architect, Red Hat (host/moderator)
  • Joshua Dietzick — Principal Cloud Engineer, Cigna
  • Chris Porter — Director of Solution Architecture for Red Hat Advanced Cluster Security (Red Hat)

Rate this summary

Your feedback will help improve summaries.

Improve this summary

Reprocess with a stronger model when the summary feels incomplete or inaccurate.

Pro

Translate summary in another language

Pro

Ask questions to this video

Chat for follow-up questions, clarifications, and source-backed answers.

Coming soon

Share this summary

Original video