File and Object Storage

 View Only

IBM Storage Ceph Integration with IBM Security Key Lifecycle Manager (GKLM)

By Daniel Alexander Parkes posted Mon September 16, 2024 06:26 AM

  

IBM Storage Ceph Object Integration with IBM Security Key Lifecycle Manager (GKLM)

Encryption at Rest and In Transit with IBM Storage Ceph Object

As data security becomes increasingly critical in today’s digital landscape, organizations prioritize solutions protecting sensitive information. One key aspect is ensuring encryption at rest and in transit, safeguarding data from potential threats, whether stored or transferred. IBM Storage Ceph’s Object Gateway offers comprehensive options for implementing both types of encryption, often relying on key management solutions like IBM GKLM to manage and store encryption keys securely. In the following sections, we will explore how these encryption mechanisms work and the benefits they offer when used together.

Encryption at Rest with IBM Storage Ceph Object

IBM Storage Ceph Object Gateway offers robust encryption for data stored on disk, supporting granular object-level encryption. It is fully compatible with S3 encryption semantics and integrates with key management systems such as IBM GKLM, Hashicorp Vault, and Thales CipherTrust.

Encryption at rest is essential for safeguarding stored data from unauthorized access by encrypting it while it resides on disk. Ceph facilitates this process through seamless integration with external Key Management Systems (KMS) like IBM GKLM. By doing so, Ceph can automatically retrieve encryption keys from the key manager, ensuring that objects are encrypted as they are uploaded. This integration provides data security throughout its lifecycle while centralizing key management, simplifying key rotation, auditing, and overall compliance efforts.

Encryption in Transit with IBM Storage Ceph Object

Data may travel through various unknown and/or untrusted networks as it moves between the object storage and the application. By encrypting the data as it travels over the network, we can effectively prevent tampering and guarantee the data's security, regardless of its path.

In IBM Storage Ceph Object, this is typically achieved using TLS/SSL encryption, which secures communication between clients and the RGW (RADOS Gateway). Once Configured, the Object Gateways provide an S3 RESTful API over HTTPS, ensuring that all data exchanged between clients and the object storage system is encrypted and protected.

From an architectural standpoint, SSL encryption can be applied at multiple layers: at the load balancer (ingress service), RGW level, or both. For full client-to-RGW HTTPS encryption, two approaches can be configured at the load balancer level: passthrough, where encrypted traffic is forwarded at level 3/TCP directly to the Object Gateway service, or re-encrypt, where the load balancer decrypts and re-encrypts traffic before sending it to the RGW.

S3 Server-Side Encryption (SSE) Options in IBM Storage Ceph Object

Ceph Object Gateway (RGW) supports various Server-Side Encryption (SSE) methods to secure data stored in its object storage. These methods allow Ceph to automatically encrypt data as it is written, ensuring that data at rest is protected without requiring the user to manage encryption independently. Below are the supported SSE methods and their differences:

1. SSE-C (Server-Side Encryption with Customer-Provided Keys)

SSE-C allows clients to manage their own encryption keys. The client provides Ceph with a key for each object request in this mode. Ceph then uses this key to encrypt the data before storing it and must decrypt it using the same key when data is requested.

  • Key management: Handled by the client. The key is provided on every read-and-write request.
  • Advantages: Full control over the keys remains with the user, allowing for more custom security policies.
  • Disadvantages: The user bears the burden of key management. Losing the key results in the permanent loss of data.

2. SSE-S3 (Server-Side Encryption with S3 Managed Keys)

Ceph manages encryption and decryption in this configuration while leveraging external KMS to handle keys securely. SSE-S3 provides transparent encryption, ensuring that data is automatically encrypted when stored and decrypted when retrieved without requiring additional effort from the client. SSE-S3 is only supported by the Hashicorp Vault Integration.

3. SSE-KMS (Server-Side Encryption with Key Management Service)

SSE-KMS provides server-side encryption where keys are managed by an external Key Management Service (KMS) such as IBM GKLM. When using this method, Ceph will communicate with a KMS to retrieve the encryption keys for encrypting and decrypting data. The keys are stored and managed externally, which can simplify compliance.

  • Key management: Handled by the KMS (e.g., IBM GKLM).
  • Advantages: Centralized and secure key management. The KMS takes care of the entire lifecycle of the encryption keys, including auditing, rotation, and deletion.
  • Disadvantages: Requires integration with an external KMS

Introducing IBM Security Key Lifecycle Manager (GKLM)

IBM Security Guardium Key Lifecycle Manager (GKLM) is an enterprise-grade key management system designed to help organizations manage and safeguard encryption keys throughout their lifecycle. As data security demands increase and compliance requirements become stricter, centralized and secure key management becomes paramount. GKLM provides this capability while integrating seamlessly with multiple platforms, including IBM Storage Ceph.

GKLM provides centralized key management and automated key rotation, ensuring encryption keys are updated regularly without manual intervention. It also offers detailed auditing and logging to track key usage and lifecycle events. GKLM adheres to the Key Management Interoperability Protocol (KMIP), among other protocols, and provides high availability through clustering.

There is a 90-day trial to install and test GKLM available here. And if you want to test the integration,  IBM Storage Ceph also has a 60-day trial available here.

Benefits of Using IBM GKLM with IBM Storage Ceph Object

IBM Storage Ceph is now validated and certified to work with GKLM. Here is the link to the GKLM support website and the link to the updated IBM Storage Ceph Matrix documentation.

When integrated with IBM Storage Ceph Object through KMIP, IBM GKLM provides secure and compliant key management specifically for encryption at rest (SSE-KMS). This integration ensures that data is securely encrypted while stored in Ceph, using keys managed centrally by GKLM. By leveraging GKLM, organizations can enforce strict security policies for data at rest, including key rotation, auditing, and lifecycle management. Additionally, the centralized management of encryption keys simplifies compliance with regulatory requirements.

Client-side GKLM Configuration

IBM GKLM can authenticate client requests based on client certificates, providing an added layer of security in key management interactions. In a typical setup, the client (such as Ceph's Object Gateway/RGW) and GKLM are configured with trusted certificates to establish secure, mutual TLS (mTLS) communication. The client presents its certificate when requesting GKLM, which verifies the certificate against its trusted certificate authority (CA). Once authenticated, the client can request, retrieve, or manage encryption keys per the configured policies.

IBM Storage Ceph Object configuration

To integrate IBM Storage Ceph Object with IBM GKLM for server-side encryption, you must configure Ceph's Object Gateway (RGW) to communicate securely with the external Key Management System (KMS) using the KMIP protocol. The following configuration commands set up the RGW to connect to the KMS.

# ceph config set client.rgw.client-traffic rgw_crypt_s3_kms_backend kmip
# ceph config set client.rgw.client-traffic rgw_crypt_kmip_addr 192.168.122.80:5696
# ceph config set client.rgw.client-traffic rgw_crypt_kmip_client_key /var/run/ceph/rgw.s3.cephlabs.com.key
# ceph config set client.rgw.client-traffic rgw_crypt_kmip_client_cert /var/run/ceph/rgw.s3.cephlabs.com.cer
# ceph config set client.rgw rgw_crypt_require_ssl false

In this example, we are using /var/run/ceph/ as the path to place the RGW client certificate, so we don't need to modify the cephadm RGW configuration spec file, . On the Ceph hosts where the RGW service will run, copy the certificated to the directory /var/run/ceph/ and change the owner to the system ceph user:

[root@ceph-node-02 ~]# ls -l /var/run/ceph/86ffb8e8-aa60-11ee-bdaf-52540016bbfa/ | grep -v ok
total 12
-rw-------. 1 ceph ceph 3243 Mar 6 06:41 rgw.s3.cephlabs.com.key
-rw-r--r--. 1 ceph ceph 5930 Mar 6 06:41 rgw.s3.cephlabs.com.cer

This maps into /var/run/ceph/ inside the container:

[root@ceph-node-02 ~]# podman inspect ceph-86ffb8e8-aa60-11ee-bdaf-52540016bbfa-rgw-client-traffic-ceph-node-02-yntfqb | grep 'var/run/ceph'
"/var/run/ceph/86ffb8e8-aa60-11ee-bdaf-52540016bbfa:/var/run/ceph:rw,rprivate,nosuid,nodev,rbind",

GKLM client configuration

IBM GKLM can authenticate client requests based on client certificates, adding an extra layer of security to key management interactions. In a typical setup, the client (such as Ceph's RGW) and GKLM are configured with trusted certificates to establish secure, mutual TLS (mTLS) communication. When the client requests GKLM, it presents its certificate, which GKLM then verifies against its trusted certificate authority (CA). Once authenticated, the client can request, retrieve, or manage encryption keys according to the configured policies.

Here is an example, From the GKLM UI on client information, we select usage type: Ceph, Then we select client Certificate and add our RGW Certificate, so GKLM starts trusting our RGW client service:

Once the new client is created and our IBM Object Gateway certificate is trusted, you must create a symmetric key Object within GKLM to enable RGW to use IBM GKLM for encryption. Symmetric keys encrypt and decrypt data, making them ideal for server-side encryption operations in Ceph. In the GKLM UI, navigate to the cryptographic object management section and create a new symmetric key. You can specify parameters such as key size, algorithm (e.g., AES), and usage policies. Once the key is created, it will be assigned a unique key identifier (KeyID), which the RGW will reference in its requests.

Client Verification

In this verification step, we test Ceph’s RGW and IBM GKLM integration for SSE-KMS encryption. Using the AWS CLI, we upload and retrieve encrypted objects, ensuring that the specified KMS key from GKLM is used for encryption at rest. The --sse=aws:kms flag in the command specifies that server-side encryption is managed by a KMS, and the --sse-kms-key-id flag references the KMS key (identified by an alias or key ID) created in GKLM. This ensures the object is encrypted with the designated key before being stored in Ceph.

# aws --profile replica --endpoint http://ceph-node-02:8000 s3 cp /etc/hosts s3://lcbucket/encrypted4 --sse=aws:kms --sse-kms-key-id rgw0066c02f9000000002
upload: ../etc/hosts to s3://lcbucket/encrypted4
# aws --profile replica --endpoint http://ceph-node-02:8000 s3api head-object --key encrypted4 --bucket lcbucket
{
    "AcceptRanges": "bytes",
    "LastModified": "Wed, 06 Mar 2024 15:57:06 GMT",
    "ContentLength": 233,
    "ETag": "\"2ad003e8df34822d40bfbd70313382be\"",
    "ContentType": "binary/octet-stream",
    "ServerSideEncryption": "aws:kms",
    "Metadata": {},
    "SSEKMSKeyId": "rgw0066c02f9000000002"
}
# aws --profile replica --endpoint http://ceph-node-02:8000 s3 cp s3://lcbucket/encrypted4 /tmp/file
download: s3://lcbucket/encrypted4 to ../tmp/file

In another verification example, we use the PutBucketEncryption S3 API to apply default encryption settings at the bucket level. The PutBucketEncryption API allows you to specify encryption rules for a bucket, ensuring that all objects uploaded to the bucket are automatically encrypted using the specified KMS key. In this case, we define the encryption policy in a JSON file that includes our KMS key ID and the encryption algorithm (aws:kms), and then apply this configuration to the bucket using the put-bucket-encryption command.

# cat replica.json
{
    "Rules": [
    {
        "ApplyServerSideEncryptionByDefault": {
            "KMSMasterKeyID": "rgw0066c02f9000000002",
            "SSEAlgorithm": "aws:kms"
        }
    }
    ]
}
# aws --profile replica --endpoint-url=http://ceph-node-02:8000 s3api put-bucket-encryption --bucket bucketreplica --server-side-encryption-configuration file://replica.json
# aws --profile replica --endpoint http://ceph-node-02:8000 s3 cp /etc/hosts s3://bucketreplica
upload: ../etc/hosts to s3://bucketreplica/hosts
# aws --profile replica --endpoint http://ceph-node-02:8000 s3api head-object --key hosts --bucket bucketreplica
{
    "AcceptRanges": "bytes",
    "LastModified": "Wed, 06 Mar 2024 16:26:01 GMT",
    "ContentLength": 233,
    "ETag": "\"2ad003e8df34822d40bfbd70313382be\"",
    "ContentType": "binary/octet-stream",
    "ServerSideEncryption": "aws:kms",
    "Metadata": {},
    "SSEKMSKeyId": "rgw0066c02f9000000002"
}

Conclusion

Integrating IBM Storage Ceph Object with IBM GKLM for server-side encryption offers a robust and secure solution for effectively managing encryption keys and safeguarding data at rest. By utilizing the KMIP protocol and configuring the Ceph Object Gateway (RGW) to communicate with GKLM, users can confidently ensure that their data is securely encrypted while maintaining centralized control over key management, rotation, and auditing. 

0 comments
28 views

Permalink