Hi Nicholas, Unfortunately I can't see any great solutions here. It's a bit like asking 'if I give my house keys to this guy on the street, how do I stop them accessing my fridge?'. As a general rule, the Unix root user is the key to the castle. It is the user that must be protected at all costs, and is inherently the authorized user. The best protection you can create is protecting access to the root user. In the situation you're proposing, you are implying you cannot trust who has access to the root user so in a sense you're vulnerable right out of the gate. It's hard to claw back from that. At the moment, encrypting the sensitive properties is the main option NiFi can provide to secure sensitive information in the flow.xml.gz and there are ways to store that encryption key remotely and reduce access from unauthorized users. However, the unfortunate fact of the root user is that, there are so many ways that the root user could gain access to the sensitive information you want to protect, even if the flow.xml.gz were completely encrypted. The root user could dump the unencrypted flow definition from memory for example, and potentially the encryption key that was used to decrypt the file for runtime. The root user could also do a lot of other nasty things, regardless of whether the flow.xml.gz was completely encrypted at rest.
Potentially, docker provides the ability to restrict access/provide security controls, or some SELinux policy may be able to restrict access. But I do not see a way from NiFi's perspective to provide the protection you would need in this specific scenario. My guess is that the consultant has created a flow definition that they consider their intellectual property or something similar, and want to protect it. As it stands today, I cannot see a solution for this information to be protected in the way that it would need to be. The NiFi machine/flow would instead need to be privately hosted by the consultant and provided as a data service to the customer. Overall this is not an uncommon scenario for proprietary services that need to be kept secret, and is not unique to NiFi, so the solution is likely self-hosting to control who has access. Hope that helps, Nathan On Mon, Jan 10, 2022 at 8:17 AM Nicolas Belot <[email protected]> wrote: > Hello > > > > I have provided nifi 1.15 in a docker image for one on the company > consultant. This image (among others) will be deployed for one of our > customers. > > > > The consultant asked me to “protect” the flow.xml.gz file, especially > from the team responsible of managing the servers. > > He would want this file protected from unwanted access from user, such as > root. > > > > I know that the UI can be secured by https + user/password. But my main > concern are the following access: > > Docker exec : > > Running “Docker exec” from the host grants access to the whole container > and therefore the flow.xml.gz. > > > > Volume > > The nifi conf dir is exposed through a docker volume. The flow.xml.gz can > be thus accessed from the host running docker. > > > > Does someone have an idea about how to “secure” the file flow.xml.gz ? can > Nifi apply a password or encrypt the gz file ? > > > > Note : The goal is to secure the whole file. Crypting the sensitive > propereties is out of scope here, for the moment. > > > > Thanks in advance. > > > > N. >
