Deploying a GREP11 server on IBM Secure Execution for Linux

You can use IBM Secure Execution for Linux to protect the data of workloads that run in a KVM guest, from being inspected or modified by the server environment. To run a GREP11 server container on a KVM guest that is protected by IBM Secure Execution for Linux, see Introducing IBM Secure Execution for Linux for more information about preparing a KVM guest.

Notes:

  • To run a GREP11 server container on IBM Secure Execution for Linux, follow the instructions here.
  • You can use your design and implementation to run the GREP11 server container on a KVM guest protected by IBM Secure Execution.

Starting a GREP11 server within the KVM guest on IBM Secure Execution for Linux

Complete the following steps:

  1. Prepare GREP11 server image
  2. Prepare configuration files for c16 client
  3. Prepare configuration files for GREP11 server
  4. Deploy GREP11 server

1. Prepare GREP11 server image

Load the GREP11 server image from the tar archive. If you don't have the tar archive, see Downloading Crypto Express Network API for Secure Execution Enclaves.

Record the tag of the image, which is required to construct docker-compose.yml in Step 4.1.

docker load -i grep11server_s390x_1.1.2.1.tar

The following snippet shows an example of the output:

Loaded image: sys-hpcs-team-grep11-docker-local.artifactory.swg-devops.com/grep11-c16:grep11server_s390x-1.1.2.1

2. Prepare configuration files for c16 client

Prepare and collect the following files that are required for the c16 client to connect to the c16 server.

Filename Description
c16client.yaml c16 client configuration file
c16server-ca.pem c16server CA root certificate (used as CA root on client side in mTLS connection with c16server)
c16server-client.key c16server client private key (used as client key on client side in mTLS connection with c16server)
c16server-client.pem c16server client certificates (used as client certificate on client side in mTLS connection with c16server)
c16server-restricted-server.pem c16server server certificate (used to do restricted server certificate validation, which will ensure only the permitted target server (which is the same as the one used on the c16server side) can be accessed)

Sample of the c16client.yaml file:

#trace, debug, info, warn, err, error, critical, off
loglevel: 'debug'
servers:
  - hostname: ${C16SERVER_IP}
    port: 9001
    mTLS: true
    server_cert_file: "/cfg/c16server-ca.pem"
    client_key_file: "/cfg/c16server-client.key"
    client_cert_file: "/cfg/c16server-client.pem"
    restrict_server_cert_file: "/cfg/c16server-restricted-server.pem"  #optional
    EOF

Where C16SERVER_IP: Is the IP address of the c16 server.

Note:

  1. If no restrict_server_cert_file parameter is set or it is empty, then c16client will work normally.
  2. If you want to restrict the server accessibility, set the parameter restrict_server_cert_file to the right c16server certificate.

Trouble Shooting: If restrict_server_cert_file is set, and you see the following error message from the server:

grep11server-ep11server-1  | [c16client][error] c16client::c16OpenAdapter: Failed to verify the identity of target server, please re-config and connect with permitted server.

Ensure that you do the following:

  1. Set the parameter restrict_server_cert_file with the correct c16server certificate.
  2. Connect to the target c16server.

3. Prepare configuration files for GREP11 server

Prepare and collect the following files that are required for configuring the GREP11 server.

Filename Description
grep11server.yaml GREP11 server configuration file
grep11-ca.pem GREP11 server CA certificates(used as CA root on GREP11server side in mTLS connection)
grep11-server.key GREP11 server server private key(used as server key on GREP11server side in mTLS connection)
grep11-server.pem GREP11 server server certificates(used as server certificate on GREP11server side in mTLS connection)

HSM domain values of c16server can be acquired from this step Configuring Crypto Express Card Domain.

Sample of grep11server.yaml:

#
# Copyright IBM Corp. All Rights Reserved.
#
# SPDX-License-Identifier: Apache-2.0
#
logging:
  # Package log levels
  # Levels: info, warning, debug, error, fatal, trace, and panic
  levels:
    # example below
    # entry: debug
###################################
## GRPC SERVICES TALKING TO GREP11 server ##
ep11crypto:
  enabled: true
  connection:
    address: 0.0.0.0
    port: 9876
    # Secure connection TLS options
    tls:
      enabled: true
      # certfile, keyfilie and cacert refer to the pem files that holds the certs
      certfile: /cfg/grep11-server.pem
      keyfile: /cfg/grep11-server.key
      mutual: true
      cacert: /cfg/grep11-ca.pem
      # same as above, but instead of filename, contents of PEM can be in an environment
      # variable (i.e. to avoid mounting files into docker container)
      cacertbytes:
      certfilebytes:
      keyfilebytes:
    # Server TCP/IP connection monitoring
    # serverKeepaliveTime is the duration in seconds after which if the server
    # does not see any activity from the client it pings the client to see
    # if it is alive
    # serverKeepaliveTimeout is the duration the server waits for a response
    # from the client after sending a ping before closing the connection
    keepalive:
      serverKeepaliveTime: 30
      serverKeepaliveTimeout: 5
  # A single card.domain tuple in hex
  # Example: "1.a" correspods 10th domain on the first card
  domain: "${C16SERVER_HSM_DOMAIN}"

Where Where C16SERVER_HSM_DOMAIN is a single card.domain tuple, e.g., "00.003a", that is configured on the c16server. A maximum of one domain is supported. In addition, only use the domain which has been granted access permission for the client. For more information, see Bind client certificate to target domain.

The following diagram shows the certificates that are used to configure the GREP11 server

Certificates to configure GREP 11 server Figure 1. Certificates to configure GREP 11 server

4. Deploy GREP11 server

4.1 Prepare docker-compose.yml

Prepare docker-compose.yml, which is used to boot up the GREP11 server container.

Note: You must change the image tag to grep11server image.

Sample of docker-compose.yml:

services:
  ep11server:
    user: "0"
    image: ${GREP11SERVER_IMAGE_TAG}
    ports:
      - 9876:9876
    volumes:
      - ./c16client.yaml:/etc/c16/c16client.yaml
      - ./c16-ca.pem:/cfg/c16server-ca.pem
      - ./c16-client.key:/cfg/c16server-client.key
      - ./c16-client.pem:/cfg/c16server-client.pem
      - ./grep11server.yaml:/etc/ep11server/ep11server.yaml
      - ./grep11-ca.pem:/cfg/grep11-ca.pem
      - ./grep11-server.pem:/cfg/grep11-server.pem
      - ./grep11-server.key:/cfg/grep11-server.key

Where GREP11SERVER_IMAGE_TAG is the grep11server image tag, like "us.icr.io/crypto-appliance/grep11server:s390x-1.1.2@sha256:54334c919a93c45f70d0252d8518d24b64255a88a073b35239f95d056d444ab8"

For single or multiple containers, you can also use the play subsection. In the play subsection, you can define the workload via Pod descriptors. Each pod can contain one or more container definitions. Descriptors can be provided as shown in the following example:

apiVersion: v1
kind: Pod
metadata:
  name: grep11server
spec:
  securityContext:
    privileged: true
  containers:
  - name: grep11server
    image: ${GREP11SERVER_IMAGE_TAG}
    volumeMounts:
    - name: c16-client
      mountPath: /etc/c16/c16client.yaml
    - name: c16-ca
      mountPath: /cfg/c16server-ca.pem
    - name: c16-client-key
      mountPath: /cfg/c16server-client.key
    - name: c16-client-pem
      mountPath: /cfg/c16server-client.pem
    - name: grep11-config
      mountPath: /etc/ep11server/ep11server.yaml
    - name: grep11-ca
      mountPath: /cfg/grep11-ca.pem
    - name: grep11-server-pem
      mountPath: /cfg/grep11-server.pem
    - name: grep11-server-key
      mountPath: /cfg/grep11-server.key
    securityContext:
      privileged: true
    ports:
    - containerPort: 9876
      hostPort: 9876
  volumes:
  - name: c16-client
    hostPath:
      path: ./c16client.yaml
      type: FileOrCreate
  - name: c16-ca
    hostPath:
      path: ./c16-ca.pem
      type: FileOrCreate
  - name: c16-client-key
    hostPath:
      path: ./c16-client.key
      type: FileOrCreate
  - name: c16-client-pem
    hostPath:
      path: ./c16-client.pem
      type: FileOrCreate
  - name: grep11-config
    hostPath:
      path: ./grep11server.yaml
      type: FileOrCreate
  - name: grep11-ca
    hostPath:
      path: ./grep11-ca.pem
      type: FileOrCreate
  - name: grep11-server-pem
    hostPath:
      path: ./grep11-server.pem
      type: FileOrCreate
  - name: grep11-server-key
    hostPath:
      path: ./grep11-server.key
      type: FileOrCreate
  restartPolicy: Always

Run the chmod 777 command on all the configuration files (c16-ca.pem, c16-client.key,c16-client.pem,grep11-ca.pem,grep11-server.pem,grep11-server.key).

4.2 Deploy GREP11 server container locally

You can deploy the GREP11 server container on a local s390x server by running the following command.

docker-compose up

You can deploy the GREP11 server container on a local s390x server using Podman, by running the following command.

podman play kube grep11.yaml

5. Test the workload

If you want to access cloud HSM on IBM Cloud Hyper Protect Crypto Services remotely to perform cryptographic operations, you need to generate a GREP11 API request in your on-prem environment to enable mutual TLS authentication for GREP11 API instead of IBM Cloud IAM authentication.

Prepare the following mutual TLS client certificates for connection with GREP11 server:

Filename Description
grep11-ca.pem GREP11 server CA certificates (Used as CA root on GREP11server side in mTLS connection.)
grep11-client.key GREP11 client private key
grep11-client.pem GREP11 client public certificate

Add the following snippet into your code:

cert, _ := tls.LoadX509KeyPair("grep11-client.pem ", "grep11-client.key")
var callOpts = []grpc.DialOption{
  grpc.WithTransportCredentials(credentials.NewTLS(&tls.Config{Certificates: []tls.Certificate{cert}}))
}

Now you can perform cryptographic operations by remotely accessing the functions with the Enterprise PKCS #11 (EP11) over gRPC API calls. For more details, see Cryptographic operations: GREP11 API.