Key4C Kubernetes Resource Security Service

Key4C Kubernetes Resource Security Service is a cloud HSM-based key management service that enhances the security of Secrets, a core resource in Kubernetes environments. By default, Secrets are stored in etcd using Base64 encoding, which means they can be easily decoded by anyone—posing a risk of sensitive data leakage. While a Data Encryption Key (DEK) is often used to improve this, managing DEKs in plaintext without proper protection introduces new security vulnerabilities. Some environments attempt to strengthen security by using external KMS solutions, but these too may have structural weaknesses during authentication, transmission, or storage. Key4C mitigates these risks by using a KEK (Key Encryption Key) generated within a certified HSM (FIPS 140-2), encrypting the DEK and securely transmitting it over an authenticated and protected channel—eliminating any exposure of the DEK. The service can be easily integrated with a lightweight web console and agent, and helps organizations meet encryption key management requirements for security certifications such as ISMS-P and CSAP, making regulatory compliance easier.

Start protecting your Kubernetes Secrets today and build a secure cloud-native environment with Key4C.

1. Service Overview

The Secret ConfigMap resource is a core component in Kubernetes, but is it being properly secured? Secret ConfigMap containing sensitive information(certificates, passwords, tokens, API keys) cannot be securely protected with Kubernetes’ default storage method.

  • Secrets stored with Base64 encoding → only basic obfuscation, highly vulnerable.

  • When using the K8S KMS Plugin, it is critical to ensure the security of the KEK (Key Encryption Key) that wraps the DEK (Data Encryption Key) → if the KEK is compromised, Secret security is completely broken.

The KEK must be stored in a way that makes it impossible to extract, and a secure channel must be established when retrieving the DEK through the KEK.

2. Service Introduction

1

Easy deployment optimized for cloud

Our cloud-based SaaS model reduces the burden of security updates and maintenance, enabling fast and easy deployment

2

Secure channel for DEK encryption and decryption

Only authenticated requests via the agent trigger encryption/decryption, with secure communication ensured by HSM-issued certificates

3

Secret protection with HSM-based keys

DEKs are encrypted with HSM-generated KEKs, which are never exposed, preventing decryption even if a DEK is compromised

4

Certified for GDPR, HIPAA, PCI DSS, CCPA and more

In regulated industries, Kubernetes environments require strict compliance with encryption and key management policies, including key separation and decryption request validation

Compliance with high-level international regulations such as GDPR, HIPAA, and PCI DSS is ensured.

GDPR : General Data Protection Regulation

HIPAA : Health Insurance Portability and Accountability Act

PCI DSS : Payment Card industry Data Security Standard

CCPA : California Consumer Privacy Act

3. Service Implementation: Before & After

While Kubernetes offers great convenience, it also hides security risks. Strengthen your environment with proper key management and encryption to enhance security for complete protection.

3-1. Before implementation

  • Secrets stored in etcd with Base64 encoding > Easily exposed as plaintext

  • DEK or KEK stored locally > High risk of key theft and decryption

  • No TLS or authentication for KEK access > Vulnerable to MITM attacks

  • Inadequate security controls > Unable to meet certification and requirements

3-2. After implementation

  • EK-encrypted secrets in etcd > Prevents plaintext exposure

  • KEK generated/stored in HSM > Blocks key leakage

  • Secure channel via HSM certificate > Prevents MITM attacks

  • Key separation in HSM > Strengthens key control and compliance

  • Using securely stored KEK to access DEK > Minimizes plaintext DEK exposure

4. Feature

4-1. Secure Key Generation

Easy and fast key generation and management through a web-based GUI

Secure KEK generation based on HSM with no risk of key exposure

  • Generate KEKs easily via web console and manage them centrally

  • KEK keys are generated inside the HSM, eliminating the risk of external exposure, and are used to encrypt and decrypt DEKs.

  • The DEK is encrypted using AES-GCM.

  • Supports auto/manual key generation, external key import & combine, and KCV validation

4-2. Secure use of DEKs

Minimized DEK usage with maximized security with simple Agent integration

Secure Communication via Certificate-Based Authentication

  • Agent and Key4C perform mutual authentication using HSM-issued certificates to establish a secure channel automatically

  • Only verified requests are executed, blocking man-in-the-middle attacks and tampering; DEKs remain protected

  • DEK encryption/decryption occurs inside the HSM, with results securely sent to the Agent

  • API Server stores encrypted secrets in etcd and decrypts them safely when requested, delivering to Worker Nodes

KEK that enhances DEK security

  • KEKs are generated and stored exclusively within the HSM, preventing any external leakage

  • All encryption and decryption operations occur inside the HSM, so KEKs never reside in memory or disk

  • When needed, the encrypted DEK (Data Encryption Key) is decrypted and used.

  • DEKs are stored in etcd only in KEK-encrypted form; even if leaked, they cannot be decrypted and are therefore useless

  • Compliant with domestic and international standards such as ISMS-P and CSAP, facilitating certification

5. Service Workflow Diagram

5.1 When storing Secret

5.2 When using Secret