Enable authentication for internal redis

[stefannica]

Enable password authentication for the internal redis service.

Signed-off-by: Stefan Nica [email protected]

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 61.96%. Comparing base (5293c8f) to head (b4e48f3). Report is 2156 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #13270      +/-   ##
==========================================
+ Coverage   61.87%   61.96%   +0.08%     
==========================================
  Files         914      914              
  Lines       54309    54101     -208     
  Branches     2020     2020              
==========================================
- Hits        33605    33521      -84     
+ Misses      16925    16821     -104     
+ Partials     3779     3759      -20     

Flag	Coverage Δ
unittests	61.96% <ø> (+0.08%)	:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

see 11 files with indirect coverage changes

[mfriess2]

Will this PR come into Harbor any time soon? Because Harbor's unsecured redis server is reported by security tools.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Vad1mo]

hey @goharbor/maintainers, i think that would still make sense! Should we work toward merging this PR?

[MinerYang]

Will this PR come into Harbor any time soon? Because Harbor's unsecured redis server is reported by security tools.

We would like to know what these security tools are and what the security concern it is by not setting the internal redis password. Based on our knowledge, this internal redis can not access externally. If you have permission to access the internal redis, it basically means you can get all the harbor configurations. Consider to this situation, if you intend to do something bad simply adding a password wouldn't be helping more. And it only stores cache data like metadata from distribution, nothing sensitive as far as I know.

So we are happy to have a discussion on this.

[mfriess2]

Thank you for your reply.

Let me try to elaborate the risk bit more:

The problem was reported by a Nessus Security Scanner (from Tenable) as a "critical" finding! See details here: https://www.tenable.com/plugins/nessus/100634

The attack scenario can be:

• You have some container running in your cluster which has a security vulnerability and is exposed to the internet (meaning: not Harbor but some other 3rd party container).
• Someone achieves to exploit this vulnerability and gets shell access into that container in your cluster
• Now the attacker is in your cluster's network (note: without having kubectl control !!!)
• He can now scan the cluster for open ports and connect to your redis container without authorization (e.g. by just using "curl" in the exploited container)

Example:

Is it that much effort to put a password on redis and use the password in the harbor communication?

[qnetter]

I agree that this is a significant issue. So much of the cloud-native universe has been designed with the assumption of a friendly world with properly configured network boundaries - a naïve assumption.

[MinerYang]

True, thanks for your follow-up elaboration! We will have a discuss on this and evaluate the risk with my colleague soon.

[MinerYang]

We have a discussion with security team. And they agree with the risk described above by @mfriess2. We probably consider to set this password configuration for internal Redis server as optional. Since current default setting of it is using a unauthenticated way (without password) and if we plan to change the default configuration, there would be an issue with upgrade/migration. So we need take care of this more specifically. And welcome to have more discussion and feedback from the community!

[MinerYang]

we will evaluate change behavior for downstream consumer like harbor-helm etc. And plan this as a feature for next release cycle (2.9.0)