Skip to content

Add PKCS12 Keystore support for OPA server client cert, CA cert and private key files #7107

Open
@mariuspodean

Description

@mariuspodean

What is the underlying problem you're trying to solve?

In some scenarios it is not feasible to have stored on disk unprotected, sensitive (m)TLS files, such as the server certificate and its private key. Using a password protected keystore improves security in this situation.

Currently, in order to use (m)TLS, we need to pass as params the paths for the following files: server cert & private key and the CA cert. While there is no problem for having the CA cert on disk, there is a different matter when it comes to the certificate itself and especially for the private key. This issue is mainly present on setups that don't use (service) containers and OPA is installed alongside other pieces of software.

Keystores provide a secure way to store this sensitive information, making sure that only authorized entities can access and use the stored keys and certificates.

Describe the ideal solution

Ideally, instead of passing three params to identify the mTLS required 3 files (cert, private key and CA cert), we could pass the path where the keystore is stored and the password to access the data within it.

So instead of using:

...
--tls-cert-file cert.pem \
--tls-private-key-file key.key  \
--tls-ca-cert-file ca.pem \
...

one could use something like the following:

...
--tls-keystore-file keystore.p12 \
--tls-keystore-pass secret \
...

As not everyone needs this level of control, probably both methods for configuring TLS should be in place, leaving to the user to choose.

Ideally we would use PKCS12 keystores, but, if for some reasons that's not possible, JKS would be OK too.
PKCS12 is a standardized and language-neutral way of storing encrypted private keys and certificates, and one can use something like the following to bundle together in a secured way the resources:

openssl pkcs12 -export \
    -in cert.pem \
    -inkey cert_key.key \
    -chain \
    -CAfile CA.pem \
    -out keystore_name.p12 \
    -passout keystore_pass \
    -name resources_name_in_keystore

Describe a "Good Enough" solution

The goal here is to protect sensitive resources (server cert & key) and the best way to do it is through the use of keystores. If that is not something that's on the scope for OPA (although one might argue that such a component should use "all means" to secure itself), allowing password protected keys would also be a step up.

Password protected keys would require that we pass an additional param, the key's password. This approach allows us to secure one resource (the certs private key), but leaves the server cert exposed.

Additional Context

All this might not make sense for some setups were we ca use other infra means to protect these resources, but please bear in mind that that's not always possible.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions