Masking and mounting
Automatic masking of confidential contract values and read-only mounting of the masked contract to the container namespace for enhanced security.
IBM Confidential Computing Containers for Red Hat OpenShift Container Platform (CCCO) now includes automatic masking and mounting capabilities for enhanced security and to protect confidential data throughout the container lifecycle. This feature operates transparently without requiring configuration changes to existing deployments.
Key capabilities
- Automatic data masking - The following confidential keys in the decrypted
contract are automatically masked after consumption by services, replacing sensitive values with
secure placeholders:
iamApiKey- Logging instance API keypolicy- Rego policypassword- Private image passwordseed- Seed valueverificationKey- Sealed secret verification keydecryptionKey- Sealed secret decryption key
Note: User-specific parameters defined in both workload and env sections are not masked and remain accessible in the mounted contract. - Secure contract mounting - The masked contract is mounted with read-only
permissions to
/var/hyperprotectin the container namespace. Applications running in CCCO containers can access the masked contract atvar/hyperprotect/user-data.decrypted. - Confidential file cleanup - The following files containing sensitive data
are automatically removed from the CCCO VM after their content is consumed:
workload-verification-key.pem- Sealed secret workload verification keyworkload-decryption-key.pem- Sealed secret workload decryption keyenv-verification-key.pem- Sealed secret environment verification keyenv-decryption-key.pem- Sealed secret environment decryption keyvolumes.json- Volume configuration (for Bare Metal deployments only)auth.json- Private image authentication
- Deployment flexibility - Supports both Bare Metal and Peer Pod deployment models with deployment-specific optimizations
Security benefits
- Reduces risk of credential theft and data leakage.
- Minimizes attack surface by removing confidential data after use.
- Provides read-only access to contract structure for validation.
- Implements security-first failure handling to prevent exposure of unmasked data.
Example masked contract
The following is an example of masked user-data.decrypted file mounted with
read-only permissions to /var/hyperprotect in the container namespace.
boot: 'sehdr: SUJNU2VjRXgAAAEAAAAFUIwCOGUrdZ.…....'
env: |-
type: env
volumes:
pgblock:
seed: ***MASKED***
pgblock2:
seed: ***MASKED***
confidential-containers:
secret:
decryptionKey: ***MASKED***
verificationKey: ***MASKED***
host-attestation:
HKD-3931-0275D38:
description: KEY-1
host-key-doc: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0.….….
logging:
logRouter:
hostname: 272657f8-fcd2-4155-9462-9ef2cc9a1e39.ingress.eu-gb.logs.cloud.ibm.com
iamApiKey: ***MASKED***
parameter:
deployment-id: prod-001
region: us-east
signingKey: LS0tLS1CRUdJTiBQVUJMSUMgS0VZLS0tLS.….…..
envWorkloadSignature: Dscw0PWdGDtcmMGyg8oHCS+iirYq9.…...
workload: |-
type: workload
auths:
us.icr.io:
username: iamapikey
password: ***MASKED***
volumes:
pgblock:
mount: /mnt/data/device1
seed: ***MASKED***
filesystem: xfs
pgblock2:
mount: /mnt/data/device2
seed: ***MASKED***
filesystem: ext4
confidential-containers:
regoValidator:
policy: ***MASKED***
parameter:
mykey: myvalue
app-version: "1.2.2"
iamApiKeydecryptionKeyverificationKeyseedpassword
Whereas, the user-specific parameter values, such as my key,
app-version, deployment-id, region remain
unmasked and accessible in the mounted contract file.