Enhance Docker Image Security for Kubernetes Deployment

[germanattanasio]

When deploying this Docker image in a Kubernetes cluster, I've had to disable key security features, namely running as a non-root user and disallowing privilege escalation. To improve security posture, I propose these enhancements:

1. Modify the Dockerfile to create a non-root user that has read/write access to the working directory.
2. Remove the necessity for privilege escalation, aligning the image with Kubernetes' best practices.

I often use the following securityContext in my Kubernetes deployments or StatefulSets:

    securityContext:
      runAsUser: 1001
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL

Implementing these changes will make it easier for users to adhere to security best practices without requiring manual adjustments.

[seebeen]

It's a bit complex.

This repo basically clones this repository, makes some minor tweaks in order for the docker build to work on arm64 and builds it as is.

Regarding the capabilities, IPC_LOCK is (unfortunately) needed for the gnome-keyring which is used by the keytar library, which in turn provides the encryption for the app data. Did you get the container running without it in a non-kubernetes env? (Swarm, compose, docker run)

Regarding running it as a non-root user. I think that can be added to the dockerfile itself. Again - did you manage to run it and persist data across restarts as a non-root user?

Looking forward to your reply.

[seebeen]

P.S. I'm more than happy to make minor changes, but I've lost more sleep over this repo and getting it to run on Arm64 than intitially planned.

I think it's insane that a multi-billion dollar company can't release a docker container for Arm64.

[germanattanasio]

Hi @seebeen, I got it running in a dev namespace where non-root restrictions aren't an issue.

After experimenting with v2, I don't see significant improvements over v1. So, the team prefers sticking with the old version for now. We will probably not need this.

Thanks for crafting this Dockerfile. It does the job and solves the issue caused by the multi-billion dollar company's lack of support.

[germanattanasio]

@seebeen Take a look at https://github.com/RedisInsight/RedisInsight/issues/2561

[seebeen]

Hi. Me and @lazarivkovic are working on improving the docker build process and fixing up some of their regression bugs they've introduced.

Can you try using their workaround for the db dir, and not use the IPC_LOCK. I need to see what happens on the startup in your environment (if there are any startup errors).

[seebeen]

Hello Again.

We've reworked the entire process of setting up the docker image. I've tried using ksecretservice instead of gnome-keyring but no dice.

IPC_LOCK needs to be enabled in order for the redis passwords to be encrypted in the redis-insight app.

There is an option to keep the plain passwords, by disabling the encryption. In that manner we can disable gnome-keyring and it will work without the IPC_LOCK.

Tbh, I'm not sure what to do and if the encryption is even needed - since the insight instance sholud never be publicly available.

[germanattanasio]

Plain passwords are OK as long as you manage permissions for SSHing into the pod or reading environment variables with Kubernetes.

We use secrets that are added as environment variables during runtime.

[seebeen]

Meaning Gnome-keyring is useless in that type of deployment? Or did I misunderstand you? :)

[germanattanasio]

Gnore-keyring is useless Kubernetes employs another way to store and retrieve sensitive information

[seebeen]

I can confirm locally that removing gnome-keyring and dbus-daemon doesn't break any functionality regarding the app itself. We will remove those in the next release and move to alpine most likely.

Thank you so much for your feedback. It was immensely helpful!

[oblakbot]

:tada: This issue has been resolved in version 2.0.0 :tada:

The release is available on GitHub release

Your semantic-release bot :package::rocket:

[seebeen]

P.S. I hope you don't mind the readme mention 😅.

If you do, LMK so I can remove it 🍺