Securing a Regulated Banking OpenShift Environment

I would secure the platform using defence in depth and zero trust, assuming that no user, workload, image, network flow, or administrative action is trusted automatically.

Identity and MFA
       │
       ▼
Least-privilege RBAC
       │
       ▼
Admission controls and SCC
       │
       ▼
Signed and scanned images
       │
       ▼
Namespace and network isolation
       │
       ▼
Secrets and data encryption
       │
       ▼
Runtime monitoring
       │
       ▼
Immutable audit trail and compliance evidence

The central design principles are:

• Least privilege
• Separation of duties
• Default deny
• Immutable infrastructure
• Signed software supply chain
• Encryption everywhere
• Continuous compliance
• Complete auditability
• Automated remediation

1. Platform Segmentation

I would not place every banking workload in one shared security boundary.

Use separate clusters or clearly isolated environments for:

Production
Non-production
Development
PCI/cardholder workloads
Internet-facing workloads
Internal banking workloads
Security and management services

Where the regulatory or risk boundary is strong, use a separate OpenShift cluster, not only a namespace.

A typical architecture would be:

                         Enterprise Identity Provider
                              MFA / Conditional Access
                                        │
                                        ▼
                              OpenShift OAuth
                                        │
                         ┌──────────────┴──────────────┐
                         │                             │
                 Management cluster             Production fleet
                 ACM / GitOps / ACS                    │
                                                      ├── PCI cluster
                                                      ├── Core banking cluster
                                                      ├── Digital banking cluster
                                                      └── Shared services cluster

Management endpoints should use private connectivity, controlled administrative workstations, bastion access, and dedicated privileged-access workflows.

2. Identity and RBAC

Enterprise identity

Integrate OpenShift OAuth with the bank’s enterprise identity provider, such as:

• Microsoft Entra ID
• Active Directory through LDAP
• OIDC
• Corporate SSO

Require:

• Multifactor authentication
• Conditional access
• Central account lifecycle management
• No routine use of local OpenShift accounts
• Immediate disabling of terminated users
• Periodic access recertification

OpenShift provides RBAC through roles, cluster roles, role bindings, and cluster role bindings; recent OpenShift versions also avoid granting default cluster-role access to unauthenticated groups. (Red Hat Documentation)

Group-based access

Never bind production permissions directly to individual users unless it is an emergency exception.

Identity provider group
       │
       ▼
OpenShift group
       │
       ▼
RoleBinding or ClusterRoleBinding

Example model:

Least-privilege roles

Avoid granting:

cluster-admin
admin across all namespaces
edit where only deployment access is required
wildcard verbs or resources

Instead, create narrowly scoped roles.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: payments-deployer
  namespace: payments-prod
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch", "patch", "update"]
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]

This role cannot:

• Read Secrets
• Create RoleBindings
• Modify SCCs
• Access other namespaces
• Create privileged workloads

Separation of duties

Banking controls should separate:

• Cluster administration
• Security policy administration
• Application deployment
• Database administration
• Audit review
• Key management
• Pipeline administration

A platform administrator should not automatically have permission to approve their own production application release.

Privileged-access management

Use just-in-time privileged access:

Access request
    ↓
Manager/security approval
    ↓
Temporary group membership
    ↓
Time-limited administrative session
    ↓
Audit and session review
    ↓
Automatic removal

Keep the kubeadmin credential only for initial provisioning or controlled recovery, then remove or tightly escrow it after enterprise identity is working.

Service accounts

Each application should use a dedicated service account.

Avoid:

• Reusing the default service account
• Long-lived static service-account tokens
• Sharing service accounts between applications
• Granting cluster-wide access to workloads

Prefer projected, short-lived service-account tokens and disable token automounting where no Kubernetes API access is required.

spec:
  serviceAccountName: payments-api
  automountServiceAccountToken: false

3. SCC and Pod Security

OpenShift uses Security Context Constraints to control what privileges a pod may request, including user IDs, capabilities, host access, SELinux settings and privileged execution. (Red Hat Documentation)

The default posture should be:

restricted-v2
Non-root container
No privilege escalation
All unnecessary capabilities dropped
No hostPath
No host networking
No privileged container
Read-only root filesystem where possible
Seccomp enabled
SELinux enforced

Example workload security context:

spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: payments-api
      image: registry.bank.example/payments/api@sha256:...
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
        runAsNonRoot: true
        readOnlyRootFilesystem: true

SCC design rules

Do not modify built-in SCCs.

Instead:

1. Start with restricted-v2.
2. Create a custom SCC only when there is a documented requirement.
3. Grant the custom SCC only to a specific service account.
4. Review and approve it through security governance.
5. Reassess it regularly.

Avoid assigning SCCs broadly to:

system:authenticated
system:serviceaccounts
an entire developer group

A narrowly scoped assignment might look like:

oc adm policy add-scc-to-user custom-payments-scc \
  -z payments-service-account \
  -n payments-prod

Privileged workloads

Privileged access should be reserved for validated infrastructure components such as selected storage, networking, security or node-management agents.

Control privileged workloads with:

• Dedicated namespace
• Dedicated service account
• Node selector and taints
• Restricted image registry
• Explicit SCC
• Security approval
• Runtime monitoring
• No general developer access

Use Pod Security Admission labels as an additional visibility and enforcement mechanism where appropriate; OpenShift generates alerts for pod-security admission violations that can be investigated through API audit logs. (Red Hat Documentation)

4. Network Security and NetworkPolicies

The starting model should be default deny, not open east-west networking.

Namespace created
      │
      ▼
Deny all ingress
      │
      ▼
Deny all egress
      │
      ▼
Explicitly allow required flows

Default-deny ingress

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: payments-prod
spec:
  podSelector: {}
  policyTypes:
    - Ingress

Default-deny egress

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
  namespace: payments-prod
spec:
  podSelector: {}
  policyTypes:
    - Egress

Remember that after denying egress, required flows must be allowed explicitly, including DNS and approved APIs.

Explicit application flow

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-database
  namespace: payments-prod
spec:
  podSelector:
    matchLabels:
      app: payments-db
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: payments-api
      ports:
        - protocol: TCP
          port: 5432

This should reflect an approved application data-flow diagram:

Internet
   │
   ▼
WAF
   │
   ▼
Ingress router
   │
   ▼
Frontend
   │ TCP 8443
   ▼
Payments API
   │ TCP 5432
   ▼
Database

Any flow not in the design is denied.

Network zones

Use separate ingress controllers and network zones for:

• Public traffic
• Internal employee traffic
• Partner traffic
• Administration
• PCI workloads

Public WAF → Public Ingress Controller
Internal LB → Private Ingress Controller
Admin network → API and management endpoints

Apply:

• EgressFirewall or egress gateways
• Controlled NAT
• Firewall allowlists
• Private API endpoints
• Non-overlapping network ranges
• Network-policy audit logging
• Load-balancer access logging
• DNS logging

OpenShift’s security guidance includes network isolation, egress controls and network-security audit capabilities as part of its security model. (Red Hat Documentation)

Service-to-service security

For high-value banking services, use mutual TLS through an approved service mesh or application-level mTLS:

Payments API  ← mTLS →  Fraud service
Payments API  ← mTLS →  Customer service

Use workload identities and certificate rotation rather than static shared certificates.

5. Image Security and Signing

The bank should allow only images that are:

1. Built by approved pipelines.
2. Scanned for vulnerabilities and secrets.
3. Stored in an approved registry.
4. Signed by an approved identity.
5. Referenced using an immutable digest.
6. Verified at admission or runtime.

Source commit
    ↓
SAST and dependency scan
    ↓
Build
    ↓
SBOM generation
    ↓
Container vulnerability scan
    ↓
Image signing
    ↓
Approved registry
    ↓
Admission verification
    ↓
OpenShift deployment

OpenShift 4.20 supports Sigstore-based image-signature policies through cluster image policy resources, enabling verification of image identity and signatures before permitted deployment. (Red Hat Documentation)

Registry controls

Configure:

• Approved registry allowlist
• Block unapproved public registries
• Internal registry mirrors
• TLS trust
• Immutable repositories
• Malware and vulnerability scanning
• Retention and evidence policies

At the node level, OpenShift registry configuration is propagated through the Machine Config Operator and affects the container image policy used by the runtime. (Red Hat Documentation)

Admission policy examples

Reject:

• Unsigned images
• Images from public registries
• Mutable latest tags
• Images with critical vulnerabilities
• Images running as root
• Images without approved provenance
• Images without an SBOM where required
• Images older than the bank’s permitted lifecycle

Deployment should use a digest:

image: registry.bank.example/payments/api@sha256:92d3...

not:

image: registry.bank.example/payments/api:latest

OpenShift’s zero-trust guidance explicitly supports restricting workloads to images signed by trusted signers. (Red Hat Documentation)

For disconnected or tightly controlled banking environments, oc-mirror can mirror OpenShift releases, Operators and related signatures into internal registries. (Red Hat Documentation)

6. Secrets Management

Kubernetes Secrets are not a complete enterprise secrets-management system.

I would use an external secrets manager such as:

• HashiCorp Vault
• Cloud-provider key-management and secret services
• Enterprise HSM-backed secrets platform
• External Secrets Operator with an approved provider

Application pod
      │
      ▼
Workload identity / service account
      │
      ▼
External secrets manager
      │
      ▼
Short-lived database credential

OpenShift also provides an External Secrets Operator capability in current releases for integrating external secret stores, subject to its documented operational constraints. (Red Hat Documentation)

Secrets requirements

• No secrets in Git
• No secrets in container images
• No secrets in ConfigMaps
• No secrets in pipeline logs
• No long-lived database passwords
• Automatic rotation
• Access based on workload identity
• HSM-backed key protection for critical keys
• Separate keys by environment and application
• Complete secret-access auditing

Prefer dynamic secrets:

Pod requests DB credential
       ↓
Vault validates workload identity
       ↓
Vault creates short-lived credential
       ↓
Credential expires automatically

etcd encryption

Enable etcd encryption for sensitive API resources. OpenShift documentation states that etcd data is not encrypted by default and that enabling etcd encryption adds protection if data or backups are exposed. (Red Hat Documentation)

oc patch apiserver cluster \
  --type=merge \
  -p '{"spec":{"encryption":{"type":"aescbc"}}}'

The exact encryption type and implementation should be selected according to the OpenShift version, performance testing and the bank’s cryptographic standard.

Also protect:

• etcd snapshots
• Static Kubernetes resource archives
• Encryption keys
• Backup object storage
• Recovery credentials

When etcd encryption is enabled, the static resource backup contains keys required to restore the encrypted snapshot, so Red Hat recommends storing it separately from the etcd snapshot. (Red Hat Documentation)

7. Audit Logging

OpenShift audit logs provide a chronological security record of activities performed by users, administrators and platform components. (Red Hat Documentation)

Collect audit events from:

• Kubernetes API server
• OpenShift API server
• OAuth server
• Authentication services
• Ingress
• Network controls
• Operating system
• CRI-O
• Container registry
• CI/CD
• GitOps
• Secrets manager
• Cloud or virtualization layer

Audit policy

Choose an audit profile that satisfies regulatory requirements without overwhelming control-plane storage.

OpenShift supports configurable audit profiles that determine the level of API request detail recorded; higher-detail profiles provide more information but increase resource overhead. (Red Hat Documentation)

Events of particular interest include:

• Authentication failures
• cluster-admin use
• RoleBinding and ClusterRoleBinding changes
• SCC changes
• Secret reads
• Exec or port-forward into pods
• Namespace deletion
• NetworkPolicy changes
• Admission-policy changes
• Image-policy changes
• Certificate changes
• Audit configuration changes

Central forwarding

Audit logs must be forwarded off-cluster:

OpenShift audit logs
       │
       ▼
TLS-encrypted collector
       │
       ▼
Enterprise SIEM
       │
       ├── Detection rules
       ├── Incident response
       ├── Compliance reports
       └── Immutable archive

OpenShift Logging supports collecting, forwarding and storing logs for operational and security analysis. (Red Hat Documentation)

Banking requirements normally include:

• Write-once or immutable storage
• Restricted audit-log access
• Retention based on regulatory policy
• Time synchronization
• Integrity validation
• Alerting on logging failures
• Separation between administrators and auditors

Do not allow cluster administrators to silently delete the only copy of audit evidence.

8. Compliance

Deploy the Compliance Operator to scan both OpenShift API resources and cluster nodes against supported compliance profiles. The Operator uses OpenSCAP-based content to evaluate the cluster and identify remediation gaps. (Red Hat Documentation)

Potential frameworks include, depending on jurisdiction and bank obligations:

• PCI DSS
• NIST controls
• CIS-aligned controls
• FIPS requirements
• Internal security baselines
• Privacy and financial-sector standards

Compliance lifecycle

Define control baseline
       ↓
Run Compliance Operator scans
       ↓
Identify findings
       ↓
Risk assessment
       ↓
Test remediation
       ↓
GitOps deployment
       ↓
Rescan
       ↓
Evidence retained

Do not enable automatic remediation blindly in production. Some remediations can change MachineConfig, node configuration, scheduling behaviour or application compatibility.

Use:

• Manual approval for high-impact remediations
• Non-production validation
• Change tickets
• Rollback plans
• GitOps-controlled policy definitions
• Exceptions with owners and expiration dates

Admission governance

Use supported admission controls, Gatekeeper or enterprise policy tooling to enforce controls such as:

• Approved registries only
• Required labels and owners
• No privileged containers
• No hostPath
• Resource limits required
• Read-only filesystem required
• No NodePort without approval
• Mandatory NetworkPolicies
• Required topology constraints
• No dangerous Linux capabilities

Gatekeeper provides a validating webhook and audit functionality and can be managed through Red Hat Advanced Cluster Management for fleet-wide governance. (Red Hat Documentation)

Use failurePolicy: Fail for critical security controls only after validating webhook availability and performance, because a failed admission service can otherwise block production changes.

9. Runtime Detection

Preventive controls are not sufficient.

Use runtime detection to identify:

• Unexpected process execution
• Shell execution inside production containers
• Privilege escalation
• Suspicious network connections
• Crypto-mining behaviour
• Changes to protected files
• Access to sensitive mounted credentials
• Containers launched outside approved pipelines
• Newly exploitable vulnerable workloads

A common enterprise design uses Red Hat Advanced Cluster Security or an equivalent platform for:

Build-time scanning
Deployment policy
Runtime detection
Network visibility
Vulnerability management
Compliance reporting

Alerts should be sent to the bank’s SIEM and incident-response platform.

10. Node and Control-Plane Security

Protect nodes using:

• RHCOS-managed immutable configuration
• Machine Config Operator
• Secure Boot where supported
• TPM-backed platform controls where required
• FIPS mode when mandated
• SELinux enforcing
• Seccomp
• Minimal SSH access
• Dedicated administrative network
• Endpoint monitoring appropriate for RHCOS
• Automated patching through supported OpenShift upgrades

OpenShift’s zero-trust guidance includes trusted boot and verification controls designed to help ensure the underlying node software has not been tampered with. (Red Hat Documentation)

Never make arbitrary host changes outside the Machine Config Operator because they create configuration drift and can be overwritten or break supportability.

11. Data Protection

Use encryption:

In transit:
TLS for API, ingress, service-to-service, storage and log forwarding
At rest:
etcd, persistent volumes, object storage, registry and backups
Key protection:
Enterprise KMS or HSM

Separate:

• Encryption keys
• Encrypted data
• Backup credentials
• Recovery credentials

Apply key rotation, dual control, access logging and tested recovery procedures.

For highly sensitive workloads, consider application-level encryption in addition to infrastructure storage encryption.

12. Secure CI/CD

Production deployment should occur only through an approved pipeline.

Developer commit
      │
      ▼
Peer review
      │
      ▼
SAST / SCA / secret scan
      │
      ▼
Reproducible build
      │
      ▼
SBOM
      │
      ▼
Image scan
      │
      ▼
Signing and attestation
      │
      ▼
Production approval
      │
      ▼
GitOps reconciliation

Production users should generally not run:

oc apply -f application.yaml

directly from laptops.

Instead, GitOps provides:

• Peer-reviewed change history
• Traceability
• Declarative rollback
• Drift detection
• Separation between author and approver

Protect Git and pipeline systems as Tier-0 systems because compromise of the delivery pipeline can bypass many cluster-level controls.

13. Banking Security Control Matrix

Validation Commands

RBAC

oc auth can-i --list --as=user@example.com -n payments-prod
oc adm policy who-can get secrets -n payments-prod
oc get clusterrolebindings

SCC

oc get scc
oc describe scc restricted-v2
oc adm policy who-can use scc privileged

Network policies

oc get networkpolicy -A
oc get egressfirewall -A

Image policy

oc get clusterimagepolicy
oc get image.config.openshift.io cluster -o yaml

Compliance

oc get compliancesuites -A
oc get compliancechecks -A
oc get complianceremediations -A

Cluster health

oc get clusteroperators
oc get mcp
oc get nodes

Two-Minute Interview Answer

“I would secure a regulated banking OpenShift platform using defence in depth and zero trust. Identity would be federated to the bank’s enterprise identity provider with MFA, conditional access and group-based RBAC. I would enforce separation of duties and use time-limited privileged access rather than permanent cluster-admin rights.

Workloads would run under the restricted-v2 SCC with non-root execution, no privilege escalation, dropped capabilities, SELinux and seccomp. Any custom SCC would be narrowly assigned to a dedicated service account. Every application namespace would begin with default-deny ingress and egress NetworkPolicies, and only documented application flows would be permitted.

The software supply chain would use approved registries, vulnerability scanning, SBOMs, immutable digests and Sigstore-based image signing. Admission controls would reject unsigned, unapproved or privileged workloads. Secrets would come from an external vault using short-lived workload identities, while etcd, persistent storage, backups and all network traffic would be encrypted.

API, authentication, network, registry and administrative audit logs would be forwarded to an immutable enterprise SIEM. The Compliance Operator and policy-as-code controls would continuously assess the platform against PCI, NIST and the bank’s internal standards. Finally, GitOps would ensure that production changes are reviewed, traceable and automatically reconciled, while runtime security tooling would detect anomalous behaviour. The objective is not one control, but multiple independent layers so that failure of one layer does not expose the banking environment.”