APAC Kubernetes DevSecOps Guide 2026: Kyverno, Cosign, and Kubescape for Supply Chain Security and Policy Enforcement

The Three-Layer Kubernetes Security Model for APAC Enterprise Teams

Kubernetes security in APAC enterprise environments requires a layered approach that no single tool covers alone. The three-layer model that APAC platform engineering and DevSecOps teams are implementing in 2026:

Layer 1 — Configuration Posture: Is your APAC Kubernetes cluster and application configuration aligned with security hardening benchmarks? Are there containers running as root, missing resource limits, or RBAC paths that enable privilege escalation? Kubescape operates at this layer — auditing APAC cluster and manifest configuration against NSA/CISA, MITRE ATT&CK, and CIS frameworks.

Layer 2 — Supply Chain Integrity: Can you prove that the container images running in your APAC production Kubernetes cluster were built by your APAC CI/CD system from approved source code — and have not been tampered with after build? Cosign operates at this layer — signing images in APAC CI/CD and storing verifiable signatures in OCI registries.

Layer 3 — Runtime Policy Enforcement: Even with good configuration and signed images, can APAC development teams still deploy misconfigured or unsigned images to production? Kyverno operates at this layer — enforcing admission control policies that block unsigned images, flag security misconfigurations, and auto-remediate APAC policy deviations before resources are admitted.

This guide covers how APAC mid-market enterprises across Singapore FSI, Japanese manufacturing, and South Korean technology sectors are implementing this three-layer Kubernetes security model in 2026 — and how Kubescape, Cosign, and Kyverno work together as a coherent APAC DevSecOps toolchain.

Context: APAC Regulatory Pressure on Kubernetes Security

The acceleration of APAC Kubernetes DevSecOps in 2026 is partly driven by regulatory pressure. The joint CISA/ASD/CSA/NISC/KISA AI security guidance published in early 2026 explicitly references Kubernetes-hosted AI systems as targets for adversarial attacks, model poisoning, and supply chain compromise — creating compliance obligations for APAC critical infrastructure operators to implement input validation schemas, model provenance documentation, and AI vendor API supply chain security controls that directly map to Kubernetes supply chain security capabilities.

Beyond AI-specific guidance, MAS TRM (Singapore), HKMA SCR (Hong Kong), FSA FISC (Japan), and FSC (South Korea) operational risk frameworks increasingly reference NIST and CIS security benchmarks as baseline requirements for technology risk management. APAC financial services firms that can demonstrate Kubescape scans against CIS Kubernetes Benchmark and Cosign-signed container images in production have a substantially easier path through APAC technology risk assessments than firms that cannot provide security posture evidence.

Layer 1: Kubescape — APAC Security Posture Auditing

Starting with a cluster scan

The first action for APAC platform engineering teams adopting Kubescape is a baseline cluster scan against NSA/CISA Kubernetes Hardening Guidance — the framework most directly referenced by APAC regulatory guidance:

# Install Kubescape CLI
curl -s https://raw.githubusercontent.com/kubescape/kubescape/master/install.sh | /bin/bash

# Run NSA/CISA framework scan against APAC cluster
kubescape scan framework nsa --kubeconfig ~/.kube/apac-prod.yaml --format json \
  --output apac-cluster-nsa-baseline.json

# Run all frameworks for comprehensive APAC coverage
kubescape scan framework nsa,mitre,cis-v1.23-t1.0.1 \
  --kubeconfig ~/.kube/apac-prod.yaml \
  --format pdf \
  --output apac-security-posture-report.pdf

Typical APAC cluster first-scan findings include:

• Containers running as root (fails NSA/CISA control C-0013): APAC application containers built without explicit non-root user configuration. Remediation: add runAsNonRoot: true to pod securityContext.

• Missing resource limits (fails NSA/CISA control C-0004): APAC pods without CPU and memory limits, enabling resource exhaustion attacks. Remediation: add resources.limits to all APAC container specs.

• Privileged containers (fails MITRE ATT&CK T1611): APAC DaemonSets or system pods running with privileged: true. Remediation: replace with specific Linux capabilities using securityContext.capabilities.add.

• RBAC over-permission (fails CIS 5.1.x): APAC ServiceAccounts with cluster-admin ClusterRoleBindings or wildcard RBAC permissions. Remediation: replace cluster-admin with scoped role definitions.

CI/CD manifest scanning

The highest-leverage Kubescape deployment for APAC DevSecOps teams is scanning Kubernetes YAML and Helm charts in CI/CD before deployment — catching APAC security issues at the PR level:

# GitHub Actions step: Kubescape scan on APAC manifest changes
- name: Kubescape scan
  uses: kubescape/github-action@main
  with:
    files: "./k8s/**"
    frameworks: "nsa,mitre"
    severityThreshold: high    # fail APAC PR on high-severity findings
    format: "sarif"
    outputFile: "kubescape-results.sarif"

- name: Upload SARIF to GitHub Security
  uses: github/codeql-action/upload-sarif@v3
  with:
    sarif_file: kubescape-results.sarif

For APAC teams using Tekton or Buildkite:

# Tekton Task step / Buildkite command
kubescape scan yaml ./k8s/ \
  --framework nsa,mitre \
  --severity-threshold high \
  --format json \
  --output /workspace/kubescape-results.json

# Check exit code — Kubescape exits non-zero if threshold exceeded
if [ $? -ne 0 ]; then
  echo "APAC Kubernetes security scan failed — blocking deployment"
  exit 1
fi

RBAC visualisation for APAC multi-tenant clusters

APAC enterprises running multi-tenant Kubernetes clusters (multiple APAC business units sharing cluster infrastructure) frequently have RBAC configurations that accumulate permission grants over time, creating privilege escalation paths invisible to manual review:

# Kubescape RBAC visualisation
kubescape scan control C-0036 --format json  # check for cluster-admin usage
kubescape scan control C-0054 --format json  # check for wildcard RBAC

# Export RBAC graph for APAC security team review
kubescape viz rbac --kubeconfig ~/.kube/apac-prod.yaml \
  --output apac-rbac-graph.png

Kubescape's RBAC control checks identify the specific APAC ServiceAccount-to-ClusterRole bindings that create elevation paths — enabling APAC platform security teams to prioritise RBAC remediation by risk rather than auditing every binding manually.

Layer 2: Cosign — APAC Container Supply Chain Security

Keyless signing in APAC CI/CD

Cosign keyless signing uses the APAC CI/CD system's OIDC identity (GitHub Actions, GitLab CI, Google Cloud Build) to obtain a short-lived certificate from Sigstore's Fulcio CA — no long-lived keys to manage, rotate, or secure:

# GitHub Actions: sign APAC container image after Buildah build
- name: Sign APAC image
  if: github.ref == 'refs/heads/main'
  env:
    DIGEST: ${{ steps.build.outputs.image-digest }}
  run: |
    # Keyless signing — uses GitHub Actions OIDC token automatically
    cosign sign \
      --yes \
      apac-registry.example.com/app@${DIGEST}

    echo "APAC image signed: apac-registry.example.com/app@${DIGEST}"

Keyless signing produces a signature that records:

• The APAC image digest being signed
• The GitHub Actions workflow identity (repository, workflow, ref)
• The OIDC token claim showing the signing was from an approved APAC CI/CD workflow
• A Rekor transparency log entry with timestamp

Any APAC infrastructure team can verify this signature:

# Verify APAC container image signature
cosign verify \
  --certificate-identity-regexp "https://github.com/apac-org/app-repo/.github/workflows/.*" \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  apac-registry.example.com/app@sha256:abc123...

This verification confirms the APAC image was signed by a GitHub Actions workflow in the approved APAC repository — not by a developer's local machine or a compromised build system.

Attaching SBOMs with Cosign

Cosign's SBOM attachment enables APAC DevSecOps teams to store Software Bill of Materials documents alongside APAC container images in OCI registries for supply chain documentation:

# Generate SBOM with Syft
syft apac-registry.example.com/app:v1.2.3 -o spdx-json > apac-app-sbom.spdx.json

# Attach SBOM to APAC image in OCI registry using Cosign
cosign attach sbom \
  --sbom apac-app-sbom.spdx.json \
  --type spdx \
  apac-registry.example.com/app@sha256:abc123...

# Sign the SBOM attestation for tamper evidence
cosign attest \
  --predicate apac-app-sbom.spdx.json \
  --type spdxjson \
  apac-registry.example.com/app@sha256:abc123...

APAC regulators and auditors increasingly request SBOM documentation for software deployed in critical APAC infrastructure — Cosign SBOM attestations stored in OCI registries provide a distribution mechanism that keeps SBOMs co-located with the APAC images they document.

Air-gapped APAC environments with self-hosted Sigstore

APAC organisations with air-gapped Kubernetes deployments (common in APAC FSI, defence-adjacent, and government sectors) cannot reach Sigstore's public Fulcio CA and Rekor transparency log. Self-hosted Sigstore deployment using the sigstore-helm-operator provides the same keyless signing capability within the APAC network perimeter:

# Deploy self-hosted Sigstore components to APAC cluster
helm install fulcio sigstore/fulcio \
  --namespace sigstore-system \
  --values apac-fulcio-values.yaml

helm install rekor sigstore/rekor \
  --namespace sigstore-system \
  --values apac-rekor-values.yaml

# Configure Cosign to use APAC internal Sigstore
export COSIGN_MIRROR=https://fulcio.internal.apac.example.com
export REKOR_URL=https://rekor.internal.apac.example.com
cosign sign --yes apac-internal-registry.example.com/app@${DIGEST}

Layer 3: Kyverno — APAC Admission Policy Enforcement

Image signing verification as admission policy

With Cosign signing images in APAC CI/CD, Kyverno enforces signature verification as a Kubernetes admission control policy — blocking any APAC pod that references an unsigned image from being admitted to production:

# Kyverno ClusterPolicy: require Cosign signature on APAC production images
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: apac-require-signed-images
spec:
  validationFailureAction: Enforce
  background: false
  rules:
    - name: verify-apac-image-signature
      match:
        any:
          - resources:
              kinds: [Pod]
              namespaces: [apac-production, apac-staging]
      verifyImages:
        - imageReferences:
            - "apac-registry.example.com/app*"
          attestors:
            - count: 1
              entries:
                - keyless:
                    subject: "https://github.com/apac-org/app-repo/.github/workflows/build.yaml@refs/heads/main"
                    issuer: "https://token.actions.githubusercontent.com"
                    rekor:
                      url: https://rekor.sigstore.dev

This Kyverno policy blocks any APAC pod referencing an image from apac-registry.example.com/app* that does not have a valid Cosign keyless signature from the approved GitHub Actions workflow. An APAC developer who bypasses the CI/CD pipeline and manually pushes an unsigned image cannot deploy it to APAC production or staging environments.

Enforcing APAC security baselines

Beyond image signing, Kyverno policies enforce the security baseline controls that Kubescape identifies as misconfigured:

# Kyverno ClusterPolicy: enforce Pod Security Standards for APAC
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: apac-pod-security-baseline
spec:
  validationFailureAction: Enforce
  rules:
    # Rule 1: containers must run as non-root
    - name: require-non-root
      match:
        resources: {kinds: [Pod], namespaces: [apac-production]}
      validate:
        message: "APAC containers must run as non-root"
        pattern:
          spec:
            containers:
              - securityContext:
                  runAsNonRoot: true
    # Rule 2: containers must have resource limits
    - name: require-resource-limits
      match:
        resources: {kinds: [Pod], namespaces: [apac-production]}
      validate:
        message: "APAC containers must specify CPU and memory limits"
        pattern:
          spec:
            containers:
              - resources:
                  limits:
                    cpu: "?*"
                    memory: "?*"

Auto-generating namespace security resources

Kyverno generation policies create required security resources (NetworkPolicy, ResourceQuota) automatically when APAC teams create new namespaces — ensuring every APAC namespace has baseline isolation without requiring APAC application teams to manage it:

# Kyverno ClusterPolicy: generate default NetworkPolicy for new APAC namespaces
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: apac-default-network-policy
spec:
  rules:
    - name: generate-apac-namespace-netpol
      match:
        resources:
          kinds: [Namespace]
          selector:
            matchLabels:
              apac-team: "true"    # apply to all APAC team namespaces
      generate:
        kind: NetworkPolicy
        name: default-deny-ingress
        namespace: "{{request.object.metadata.name}}"
        data:
          spec:
            podSelector: {}        # select all pods
            policyTypes: [Ingress] # default deny all ingress

This policy ensures every APAC namespace labelled apac-team: "true" gets a default-deny NetworkPolicy at creation — implementing the network isolation baseline that Kubescape checks for and Cosign supply chain security assumes.

Integrating the Three Tools: APAC DevSecOps Pipeline

The full Kubescape → Cosign → Kyverno workflow for APAC Kubernetes DevSecOps:

Step 1 — Baseline (one-time): Run Kubescape cluster scan against NSA/CISA and CIS frameworks. Remediate high-severity findings (root containers, missing limits, RBAC over-permission). Configure Kyverno policies to enforce the remediated baseline. Accept Kubescape findings as the new policy ground truth.

Step 2 — Build-time (per APAC CI/CD run): Kubescape scans Kubernetes manifests in PR CI. Buildah (or Docker) builds the container image. Cosign signs the image digest after successful build and push to APAC dev registry. Skopeo copies signed image (with signatures) from dev to staging registry.

Step 3 — Deploy-time (per APAC staging/production deployment): Kyverno admission webhook intercepts the APAC pod creation request. Kyverno verifies the container image Cosign signature against approved CI/CD workflow identity. Kyverno validates pod security context (non-root, resource limits, no privileged). Kyverno validates image registry allowlist (only approved APAC registries). If all checks pass, pod is admitted; if any fails, admission is denied with a clear error message.

Step 4 — Continuous (periodic): Kubescape Operator runs periodic cluster scans (daily or weekly) producing updated APAC security posture reports. New Kubescape findings trigger Kyverno policy updates if new controls require enforcement. Gremlin or Chaos Mesh chaos experiments test that Kyverno webhook failures do not cascade to APAC service availability issues.

APAC Compliance Mapping

For APAC FSI firms preparing MAS TRM or HKMA SCR submissions, the combination of Kubescape CIS Kubernetes Benchmark reports + Cosign SBOM attestations + Kyverno policy configuration provides the security evidence artifacts that support APAC technology risk assessment.

Related APAC Kubernetes Security Resources

For the runtime and execution infrastructure where these security policies are enforced, see the APAC container image tooling guide covering Podman, Buildah, and Skopeo — covering the daemonless build tooling that integrates with Cosign signing in APAC CI/CD.

For the chaos engineering validation that verifies APAC Kyverno policies do not create Kubernetes availability issues, see the APAC chaos engineering guide covering Chaos Mesh, LitmusChaos, and Gremlin.

For the GitOps deployment framework that deploys Kyverno policies and application manifests to APAC Kubernetes clusters, see the APAC Kubernetes GitOps deployment guide covering Argo CD, Argo Rollouts, and Velero.