Open stanleyz opened 3 months ago
That is automatically added inside the container using the ca-certificate buildpack from here
Example when building the image:
The CA certificates are added internally as you can see in the following images:
You can add additional CA certificates as we explained here
I am not a go expert but I think the values are taken from here
yes, there is no problem adding a customised CA certificate or the ca-certificates provided by paketo-buildpacks
, the problems I saw are that:
paketo-buildpacker
and installed to jre/lib/ca-certificates
TerrakubeSSLTruststorePath
and password to be set, however, it doesn't necessarily need to because the connection should default to use the trust store provided by the JRE, and additionally with the above method provided, users can add customised CA certificates to the JRE truststore.I did some progress with this one in this PR https://github.com/AzBuilder/terrakube/pull/1391 when using REDIS and SSL
I did some progress with this one in this PR #1391 when using REDIS and SSL
Nice, thanks @alfespa17
I did more progress with this one. I was able to connect successfully to an Azure Redis with SSL enabled using the following with a custom image that I built that included the fix:
api:
version: "2.23.2+small fix from AzBuilder/terrakube#1391"
image: "api-server"
defaultRedis: false
defaultDatabase: true
loadSampleData: true
env:
- name: TerrakubeRedisSSL
value: "true"
- name: TerrakubeRedisTruststorePath
value: /layers/paketo-buildpacks_bellsoft-liberica/jre/lib/security/cacerts
- name: TerrakubeRedisTruststorePassword
value: changeit
properties:
redisHostname: "MY-REDIS-IN-AZURE.redis.cache.windows.net"
redisPassword: "MY-REDIS-ACCESS-KEY"
redisPort: "6380"
executor:
version: "2.23.2"
env:
- name: SERVICE_BINDING_ROOT
value: /mnt/platform/bindings
- name: TerrakubeRedisSSL
value: "true"
- name: TerrakubeRedisTruststorePath
value: /layers/paketo-buildpacks_bellsoft-liberica/jre/lib/security/cacerts
- name: TerrakubeRedisTruststorePassword
value: changeit
"changeit" is the default password for the java keystore included in the container by default in this path "/layers/paketo-buildpacks_bellsoft-liberica/jre/lib/security/cacerts"
The only issue that I see is that I had a huge latency from my local machine to the Azure Redis and the logs were not showing in the correct order.
So in theory the above should work to use SSL with REDIS.
Thanks @alfespa17, I will give it a try in my next upgrade. Happy for you to close this.
The only issue that I see is that I had a huge latency
I am also wondering about the performance of Azure Redis cache, will see.
Bug description 🐞
API and Executor, and likely registry as well don't use the cacerts keystore provided by the bundled JRE located in
/layers/paketo-buildpacks_bellsoft-liberica/jre/lib/security/cacerts
, which I'd assume should be the default behaviour if no customised keystone is specified.Steps to reproduce
Create a Redis cache or PostgreSQL with SSL enabled on Azure and configure Terrakube API or Executor to run with them (on SSL)
Expected behavior
The app starts without issues since the Azure root certs is already loaded into
layers/paketo-buildpacks_bellsoft-liberica/jre/lib/security/cacerts
Example repository
No response
Anything else?
No response