"immutable security" for the root certificates

[V. Sevel]

Hello,

The doc says: "When creating a native binary, GraalVM embraces the principle of "immutable security" for the root certificates."

https://quarkus.io/guides/native-and-ssl

Are there any links in the graalvm where this is discussed?

and "will ensure that the certificates of /tmp/mycerts are baked into the native binary and used in addition to the default cacerts."

what that is the recommendation when running in k8s, which provides /var/run/secrets/kubernetes.io/serviceaccount/ca.crt as the list of trusted certs?

[Georgios Andrianakis]

Hi,

On Thu, Oct 22, 2020 at 8:18 PM V. Sevel <vvs...@gmail.com> wrote:

Hello,

The doc says: "When creating a native binary, GraalVM embraces the principle of "immutable security" for the root certificates."

https://quarkus.io/guides/native-and-ssl

Are there any links in the graalvm where this is discussed?

I couldn't find the GraalVM documentation with a quick search, but the Quarkus doc is correct (and is a result of much debugging of GraalVM code).

and "will ensure that the certificates of /tmp/mycerts are baked into the native binary and used in addition to the default cacerts."

what that is the recommendation when running in k8s, which provides /var/run/secrets/kubernetes.io/serviceaccount/ca.crt as the list of trusted certs?

If you want to use these certificates in a native binary, you'll need to make sure in CI pipeline to download the certificates from the Kubernetes API Server and create/add-to the truststore and configure the Quarkus build to include it.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/e8470101-6cf5-41b6-b639-4e4ec923ca16n%40googlegroups.com.

[Foivos Zakkak]

Hello,

On 23/10/2020 07:31, Georgios Andrianakis wrote:

Hi,

On Thu, Oct 22, 2020 at 8:18 PM V. Sevel <vvs...@gmail.com> wrote:

Hello,

The doc says: "When creating a native binary, GraalVM embraces the principle of "immutable security" for the root certificates."

https://quarkus.io/guides/native-and-ssl

Are there any links in the graalvm where this is discussed?

I couldn't find the GraalVM documentation with a quick search, but the Quarkus doc is correct (and is a result of much debugging of GraalVM code).

The first place I found is in a comment inside the source code [1]:

/**
 * Native image uses the principle of "immutable security" for the root certificates: They are fixed
 * at image build time based on the the certificate configuration used for the image generator. This
 * avoids shipping a `cacerts` file or requiring to set a system property to set up root
 * certificates that are provided by the OS where the image runs.
 *
 * As a consequence, system properties such as `javax.net.ssl.trustStore` do not have an effect at
 * run time. They need to be provided at image build time.
 *
 * The implementation "freezes" the return values of TrustStoreManager managers by invoking them at
 * image build time (using reflection because the class is non-public) and returning the frozen
 * values using a substitution.
 */

and the second one is in GH issue [2] where the alternative of allowing a less strict "immutable security" policy is discussed.

HTH

Foivos

[1] https://github.com/oracle/graal/blob/0dc9d7d6e8dec7c3fd74328727c66fdea9a0fce6/substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/jdk/Target_sun_security_ssl_TrustStoreManager.java#L42-L54

[2] https://github.com/oracle/graal/issues/1999

and "will ensure that the certificates of /tmp/mycerts are baked into the native binary and used in addition to the default cacerts."

what that is the recommendation when running in k8s, which provides /var/run/secrets/kubernetes.io/serviceaccount/ca.crt as the list of trusted certs?

If you want to use these certificates in a native binary, you'll need to make sure in CI pipeline to download the certificates from the Kubernetes API Server and create/add-to the truststore and configure the Quarkus build to include it.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/e8470101-6cf5-41b6-b639-4e4ec923ca16n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-mSQ7MAzUNoA_u-%3Dub5_y_HaSnz3QKLxA_sj%2B3R85MZtg%40mail.gmail.com.

-- 
Foivos Zakkak
Senior Software Engineer, R&D Middleware
Red Hat
7B40 69D9 29BA AE91 C0B3 220A 0846 BFD1 03F0 4EA1

[Georgios Andrianakis]

Thanks for the references Foivos, they are very useful

[V. Sevel]

hello. thanks for the answer.

it certainly adds security, but adds quite a few requirements on the CI as well, considering that:

  - not all clusters share the same certificates

  - and not all clusters are accessible from the ci, 

 - and finally not all applications get deployed on a regular basis (e.g. a stable application might not be redeployed for this months, long after the certificates may have been revoked/renewed)

this would mean that 

 - certificates deployed in kubernetes should be pushed to a central place accessible from the ci

 - we should track what apps are deployed in the cluster (running applications such as deployments, and others like jobs and cronjobs) and should be redelivered

nothing that cannot be automated or organized. but that comes with a high level of maturity that may not be trivial for many companies, and brings a level of security that many do not require.

if so, it is unfortunate that graalvm would not allow the option to provide certificates at runtime.

[V. Sevel]

For the sake of completeness, the issue was discussed in https://github.com/oracle/graal/issues/1999 (including with some members of the quarkus community) as stated by Foivos, and there is already a PR submitted by Jaikiran to allow certificates configuration at run time: https://github.com/oracle/graal/pull/2831

I hope this will go through.

[Jaikiran Pai]

Hello,

On 27/10/20 10:51 am, V. Sevel wrote:
> For the sake of completeness, the issue was discussed in
> https://github.com/oracle/graal/issues/1999 (including with some
> members of the quarkus community) as stated by Foivos, and there is
> already a PR submitted by Jaikiran to allow certificates configuration
> at run time: https://github.com/oracle/graal/pull/2831
> I hope this will go through.

The PR received some initial review and inputs from the Graal team.
However, I have been tied up too much at work these past few weeks and
haven't been able to discuss those suggestions and address them. It's on
my todo list and hopefully I'll find some time soon to tackle that again.

-Jaikiran