I've been wondering how other users of KNIME Server deal with this:
When I want to automate a workflow that includes database access, I need to set a user name and a password within nodes like "Database Reader" in order to access the DB and execute queries.
Should I keep the credentials of whoever created the workflow? Should I replace them with my own? Should I create a separate "technical" user in the database only for the purpose of running automated workflows? What's best practice in this situation? How do you deal with it?
If you want every user to use their own credentials while still being able to run the workflow automatically, you can use Workflow Credentials.
First, open the workflow in your local client. Right-click the workflow in the KNIME Explorer and click "Workflow Credentials". There, you can add a new set of credentials. Use a name like "db_credentials" and leave the fields for username and password empty.
Next, go to your workflow and open the configuration of the Database Reader. Instead of entering your credentials, select "Workflow Credentials" and select the variable you just created. Save and upload to Server.
If you execute the workflow now, you will be asked to provide credentials which are then used in the workflow.
Hey Roland, thanks for the response. I've briefly checked out Workflow Credentials but not used them yet. They seem useful in many cases.
But what about scheduled workflows, e.g. a forecast that is supposed to run every morning automatically? I can put my personal credentials into the workflow, but that ties it to my personal account, which doesn't seem right. On the other hand, creating a "technical"user will use up one license and if you use LDAP auth, you'd have to create the user there.
I'm just wondering how other people handle this issue in scheduled workflows.
Hey jricgar,
unfortunately not, but I haven’t spent too much time on this problem. We placed scheduled workflows in a special folder where only the KNIME admins have access. I have the feeling that workflow credentials are not very handy and I’m still curious if there is a better way. If you figure something out, let me know.
At this point (as of KNIME Server 4.9.2), credentials should be passed via Workflow Credentials. To set this up, you need to add a set of credentials to the workflow -> right-click workflow in local repository -> Workflow Credentials. No need to save a password. In the WF, you set the DB Connector node to use those credentials. Then upload to KNIME Server. Once you run the job, either ad-hoc or on schedule, there will be a prompt asking for the credentials. Of course, the credentials you enter there can be for your generic user as well.
We’ll make this fair bit easier with the release of KNIME Server 4.10, scheduled for December release. There, we add an additional “Configuration” tab to the execution dialog, which grants you access to all configuration nodes in a workflow. All you’d need to do then is add a Credentials Configuration node to your WF, connected to the DB Connector via flow variable.
Hope that helps!
Cheers,
Roland
Edit: I need to add that the solution I mentioned for 4.9.2 will only work for EJB mountpoints. It will not work for REST mountpoints.
Is there a way to use the Credentials Configuration node to control all workflows that need to use those credentials? For example, if I have many workflows that use the same database connection can I change the credentials in one place and have all workflows use the changed credentials? Currently, I have to go into each workflow separately every time my password changes…
For this you should use a shared component, which you can then drag into as many workflows as needed. If you change something to the template, updates can be retrieved automatically by the workflows during runtime. See here for more info: https://docs.knime.com/2019-06/analytics_platform_metanode_guide/index.html
Generally speaking from a security and reliability standpoint, automation should use a “service account” that is not associated with one specific person. This allows for separate controls/polices/etc. for user accounts and system accounts.
One benefit is, say your organization forces user password changes every 60 days. They may have a different policy for service accounts that never forces them to change (not the best idea). Or maybe at a less frequent interval like once every 6 months or once a year. This keeps people from having to update a bunch of different places each time they change their own password. There are also products that can manage service accounts, their passwords and automatically update the systems using those credentials when the password is changed.
Another scenario is when a person leaves an organization and their accounts are terminated, the automation they created does not start to fail due to it using that person’s credentials which are now disabled/deleted.
Using different credentials also protects the person. With SSO being more and more prevalent, what if somebody else was able to obtain your clear-text credentials (could be in a log file)? Now they can potentially access the HR system, the email system, or other systems where you have trusted access, all as you.