Connecting a GRPC Python Client to Openshift Cluster

Published by Diwakar on March 22, 2023March 22, 2023

Hello Friends,
Lets understand the connectivity of a GRPC Python Client to Openshift Cluster. In a mutual TLS (mTLS) enabled gRPC connection, both the client and server authenticate each other using certificates. This adds an extra layer of security, as both parties must present valid certificates to establish a secure connection.

Here’s an overview of the process and the certificates involved:

1. Server-side:
   • The server must have a server certificate (e.g., server.crt) and a private key (e.g., server.key). The server certificate is usually signed by a Certificate Authority (CA).
   • The server should be configured to require clients to present a certificate, which it will verify against a trusted CA certificate (e.g., client_ca.crt). This CA certificate should be the one that signed the clients’ certificates.
   • In your OpenShift Cluster, the server certificate and private key should be stored in a Kubernetes secret and mounted as a volume in your server’s deployment configuration.
2. Client-side:
   • The client (grpc python client – grpc library) must have a client certificate (e.g., client.crt) and a private key (e.g., client.key). The client certificate should be signed by the CA that the server trusts (e.g., client_ca.crt).
   • The client should have the server’s CA certificate (e.g., server_ca.crt) to verify the server’s certificate when establishing a connection.
   • In your Python code, you should configure the gRPC client to use the client certificate and private key for authentication and the server’s CA certificate to verify the server’s certificate.

Here’s a summary of which certificates should be placed where:

• Server-side (OpenShift Cluster):
  • server.crt and server.key: Store in a Kubernetes secret, and mount it as a volume in your gRPC server’s deployment configuration.
  • client_ca.crt: Configure your gRPC server to use this certificate to verify incoming client connections.
• Client-side (Python Code):
  • client.crt and client.key: Store these files locally, and configure your Python gRPC client to use them for authentication.
  • server_ca.crt: Store this file locally, and configure your Python gRPC client to use it for verifying the server’s certificate.

Following is the flow of mTLS connection from Client to Server and Back to Client:

1. Client Hello: The client initiates the connection by sending a “Client Hello” message to the server. This message contains information about the client’s supported TLS protocol versions, cipher suites, and other extensions.
2. Server Hello: The server responds with a “Server Hello” message, selecting the TLS protocol version, cipher suite, and other parameters based on the client’s capabilities.
3. Server Certificate: The server sends its certificate (e.g., server.crt) to the client. The client will use the server’s CA certificate (e.g., server_ca.crt) to verify the server’s certificate.
4. Server Certificate Request: Since mTLS is used, the server requests a certificate from the client by sending a “Certificate Request” message. This message specifies the types of certificates the server is willing to accept from the client.
5. Server Hello Done: The server sends a “Server Hello Done” message to the client, indicating that it has finished sending its part of the handshake.
6. Client Certificate: The client responds with its own certificate (e.g., client.crt) to authenticate itself to the server.
7. Client Key Exchange: The client generates a pre-master secret, encrypts it using the server’s public key (extracted from the server’s certificate), and sends the encrypted pre-master secret to the server in a “Client Key Exchange” message.
8. Client Certificate Verify: The client sends a “Certificate Verify” message, which includes a digital signature created using the client’s private key (e.g., client.key). This signature proves to the server that the client is in possession of the private key corresponding to the public key in the client’s certificate.
9. Change Cipher Spec: Both the client and the server send “Change Cipher Spec” messages, indicating that they will now use the negotiated cipher suite and keys for communication.
10. Finished: Both the client and the server send “Finished” messages, which include a hash of the entire handshake. This hash confirms that nothing has been tampered with during the handshake process.

After these steps, the client and server have successfully established an mTLS-enabled gRPC connection. They can now securely exchange data using the negotiated cipher suite and keys.