Hi,
i’m preparing some slides for an internal presentation in order to adopt internally a fully licensed Knime server.
the IT department would like to have quite complete control over what the various users who have access to the platform do.
the installation of the desktop version on their machines will not be allowed and therefore I was wondering how access is generally given to the development environment … perhaps with access to a remote machine where, by logging in with their domain credentials, they log to their own custom workspace?
if so, is there the possibility of recording the activities of each individual user, especially the inputs and the outputs of their worflows?
thanks
Hello @Luca_Italy,
I have seen customers running KNIME in a virtual desktop environment. This can for example work using Citrix and workspaces on a network drive.
Regarding activity recording: KNIME does produce a quite detailed log file, but logging all input and output would be too data intensive. You can check the log file by going to View -> Open KNIME Log in your Analytics Platform. It is also, in my opinion, difficult to prevent the user from simply deleting the log file. Since the user needs write access to the file so that KNIME can create it, the user can in theory also delete it. Solutions like Citrix might have options to monitor log files and upload them directly to some server, though.
Kind regards,
Alexander
Ok, clear.
I’m wondering about another type of solution:
is technically possibile to remove the local workspace (hide it somehow) and force people developing workflows on teamspace or server machine?
Luca
Hi Luca,
Currently this is not really possible. We do have the Remote Workflow Editor for people to edit workflows on the server directly, i.e. use the AP only as a thin client, but not all features are 100% supported yet. Additionally the need for a workspace is pretty deeply “ingrained” in the Analytics Platform and cannot be turned off. But what you may be able to do is simply not give them access to the critical data sources from the local machines, so that workflows need to be executed on the server in order to work. For the next release we are also planning an option for KNIME Server that prevents people from downloading workflows with data, so that it will be harder to get to any sensible information.
Kind regards,
Alexander
…so that workflows need to be executed on the server in order to work.
What do you mean exactly? That a user can develop a workflow in their local workspace, but they can’t run that, so the only way to do that is publish into the server and executed there?
Luca
Hi Luca,
Yes exactly. If for example the database with the data for the workflow is only accessible from the server, the workflow needs to be published there in order to be executed.
Kind regards,
Alexander
Seems good, but that mean that workflow development will be a nightmare… every new nodes implemented have to be checked by deploying the workflow on the server… non really a viable option.
I think that the best way to have some kind of data governance on what users do is to install knime AP on a remote server, so tha an admin can monitor their workspaces if needed.
Is it correct and reasonable?
Luca
Hi Luca,
I think that the best way to have some kind of data governance on what users do is to install knime AP on a remote server, so tha an admin can monitor their workspaces if needed.
Is it correct and reasonable?
That definitely seems like a viable option. You are right that limiting data access makes building workflows harder. We do, however, have a Remote Workflow Editor that allows you to edit workflows directly on the server. It does not have all the features of the local editor yet, but is quite well usable. It is an extension you can install: KNIME Remote Workflow Editor.
Kind regards,
Alexander