is there anything new with the upgrade?

@yanji09 @ninjadq Any update on that ? Thanks

Hi, we have a plan to support TLS for Redis and the database. It might be included in a future release.

Similar asks here due to setting up Harbor with AWS ElastiCache and Azure Redis.

It seems without enabling TLS, ElastiCache doesn't even allow to enable authentication. This potentially means even though there are some level of security to be in a VPC, ElastiCache can be accidentally messed up by others in the VPC.

Similar ask from our chart users - bitnami/charts#7691

Maybe would be possible to use Redis Proxy as a sidecar as a temporary solution..

Something like:

• https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/other_protocols/redis
• https://github.com/twitter/twemproxy

use stunnel sidecar is another temp option.

https://www.stunnel.org/

You could also use a socat container to create a TLS tunnel that connects to the Redis endpoint.

• https://linux.die.net/man/1/socat
• https://blog.kloud.com.au/2017/08/03/ssl-tunneling-with-socat-in-docker-to-safely-access-azure-redis-on-port-6379/

Is there any vision on when this is going to be implemented?

FYI. trivy support TLS redis from 0.23.0, while trivy adapter does not support TLS redis yet.

This issue is being marked stale due to a period of inactivity. If this issue is still relevant, please comment or remove the stale label. Otherwise, this issue will close in 30 days.

Still an issue, please do not close.

This distribution PR hasn't been included in the distribution v2.8.1 https://github.com/distribution/distribution/pull/3161/files
We will hold this feature request until distribution new release support it.

Another security feature blocked by distribution... (the other one being AWS IAM AssumeRoleWithWebIdentity )

Distribution release v2.8.2 from May this year (which came more than a year after v2.8.1) also did not include the mentioned PR. It does not look like this feature will be added anytime soon there.

Please consider adding this feature as it makes the "supply chain" more robust and secure

I find it incredible how trivial this oft-requested feature would be to implement, and yet here we are three years later. I wanted to volunteer to implement it, but this issue's thread has suggested that would be a fool's errand.

i'm using harbor latest helm chart, but i do not know how to configure the TLS option, i'm using AWS Elastic cache for redis.

in the helm chart values.yaml file, i only see those options:

  external:
    # support redis, redis+sentinel
    # addr for redis: <host_redis>:<port_redis>
    # addr for redis+sentinel: <host_sentinel1>:<port_sentinel1>,<host_sentinel2>:<port_sentinel2>,<host_sentinel3>:<port_sentinel3>
    addr: "192.168.0.2:6379"
    # The name of the set of Redis instances to monitor, it must be set to support redis+sentinel
    sentinelMasterSet: ""
    # The "coreDatabaseIndex" must be "0" as the library Harbor
    # used doesn't support configuring it
    # harborDatabaseIndex defaults to "0", but it can be configured to "6", this config is optional
    # cacheLayerDatabaseIndex defaults to "0", but it can be configured to "7", this config is optional
    coreDatabaseIndex: "0"
    jobserviceDatabaseIndex: "1"
    registryDatabaseIndex: "2"
    trivyAdapterIndex: "5"
    # harborDatabaseIndex: "6"
    # cacheLayerDatabaseIndex: "7"
    # username field can be an empty string, and it will be authenticated against the default user
    username: ""
    password: ""
    # If using existingSecret, the key must be REDIS_PASSWORD
    existingSecret: ""```

i'm using harbor latest helm chart, but i do not know how to configure the TLS option, i'm using AWS Elastic cache for redis.

in the helm chart values.yaml file, i only see those options:

  external:
    # support redis, redis+sentinel
    # addr for redis: <host_redis>:<port_redis>
    # addr for redis+sentinel: <host_sentinel1>:<port_sentinel1>,<host_sentinel2>:<port_sentinel2>,<host_sentinel3>:<port_sentinel3>
    addr: "192.168.0.2:6379"
    # The name of the set of Redis instances to monitor, it must be set to support redis+sentinel
    sentinelMasterSet: ""
    # The "coreDatabaseIndex" must be "0" as the library Harbor
    # used doesn't support configuring it
    # harborDatabaseIndex defaults to "0", but it can be configured to "6", this config is optional
    # cacheLayerDatabaseIndex defaults to "0", but it can be configured to "7", this config is optional
    coreDatabaseIndex: "0"
    jobserviceDatabaseIndex: "1"
    registryDatabaseIndex: "2"
    trivyAdapterIndex: "5"
    # harborDatabaseIndex: "6"
    # cacheLayerDatabaseIndex: "7"
    # username field can be an empty string, and it will be authenticated against the default user
    username: ""
    password: ""
    # If using existingSecret, the key must be REDIS_PASSWORD
    existingSecret: ""```

It's not yet supported yet unfortunately. I assume support is going to be added in the 2.11.0 release.

oh ok :( thanks for the so quick reply @marevers

This distribution PR hasn't been included in the distribution v2.8.2, v2.8.3 https://github.com/distribution/distribution/pull/3161/files
We will hold this feature request until distribution new release support it.

While taking a look into distribution src, found this redisTLS config seems to be ignored in main when migrating from redigo to go-redis by this commit.
https://github.com/distribution/distribution/blob/fcbc25e7896b6ea115d1f62107483c9325b4a305/registry/handlers/app.go#L522
cc @wy65701436

progress:

• Trivy-adapter support is in progress feat: support Redis TLS aquasecurity/harbor-scanner-trivy#430
• upstream distribution still have an issue to support on this, track on redisTLS configuration support when using go-redis distribution/distribution#4284