Bulk insert credentials

[natejgardner]

For instances with many database connections, users may have the same password for many connections. Some enterprises also have password change policies that require new passwords every 90-180 days. In the case of my company, we have an enterprise password utility that bulk changes passwords for many database accounts on different servers (often, the username is also the same between servers, but in some cases it's different). We have to reset our passwords every 90 days, and since we have this tool, most users set the same password for all their accounts. Every 90 days, I update 46 passwords on three Dataiku instances, pasting the same password down the list one-by-one, which is pretty tedious. Can other users relate to this?

Instead of having users enter passwords one-by-one, it would be convenient to have an interface with checkboxes to select connections, then bulk insert a single password, username, or both into the checked connections. It would also be very convenient to be able to export the credentials as a file that could be imported into other Dataiku instances to allow users to quickly set up connections across each Dataiku instance they use.

[Marlan]

Yes @natejgardner, our experience is similar. Thanks for submitting this idea! I just finished updating my password for a couple of dozen connections on each of three instances one by one. It would be really, really nice to do this using a bulk update function.

All of our credentials are the same across databases but perhaps such a tool could filter by database / platform to enable changing credentials differently on different databases. 

Passwords should be changed for connections that already have credentials entered. Each person typically would only use some of the many connections we have. No sense in entering passwords for connections that aren't used (and with many connections it's hard to keep track of which ones are used and which ones aren't; better if the tool did that for you).

Ideally one could update passwords from one place rather than having to log into each instance separately but not a big deal if that is needed.

Marlan

[Marlan]

Yes @natejgardner, our experience is similar. Thanks for submitting this idea! I just finished updating my password for a couple of dozen connections on each of three instances one by one. It would be really, really nice to do this using a bulk update function.

All of our credentials are the same across databases but perhaps such a tool could filter by database / platform to enable changing credentials differently on different databases. 

Passwords should be changed for connections that already have credentials entered. Each person typically would only use some of the many connections we have. No sense in entering passwords for connections that aren't used (and with many connections it's hard to keep track of which ones are used and which ones aren't; better if the tool did that for you).

Ideally one could update passwords from one place rather than having to log into each instance separately but not a big deal if that is needed.

Marlan

[fsergot]

Hello Nate and others interested,

I have a few questions on this request (sorry for being late on the feedback!):

1. Are you using 'user' credentials for your connections or 'system' ones? If this is user credentials, you are using you own named creds in the connection itself? If this is system accounts, those are also following the same password expiration rules, can't you have exceptions?
2. In terms of alternatives, there are other ways to authenticate to some 3rd party, especially using oauth for those that supports it. In this case, there is no notion of password change (at worst, token renewal). Is it something you are using or considering?

As for doing something across instances, I am realistic by saying this is 

[fsergot]

Hello Nate and others interested,

I have a few questions on this request (sorry for being late on the feedback!):

1. Are you using 'user' credentials for your connections or 'system' ones? If this is user credentials, you are using you own named creds in the connection itself? If this is system accounts, those are also following the same password expiration rules, can't you have exceptions?
2. In terms of alternatives, there are other ways to authenticate to some 3rd party, especially using oauth for those that supports it. In this case, there is no notion of password change (at worst, token renewal). Is it something you are using or considering?

As for doing something across instances, I am realistic by saying this is 

[natejgardner]

Thanks @fsergot, in my case, every user has their own credentials, set in the credential manager and not in the connection settings. We don't have any exceptions to our password rules in my company, and no modern authentication methods like oauth are available, unfortunately. Even for the one database system we have in our company that supports saml authentication, MS SQL, substantial integration effort is required (it's been the full time job of a member of our admin team for nearly a year so far) to register our internal SSO system for use with DSS. But even so, for Teradata and Oracle, our company's primary database systems, we are only allowed to authenticate using passwords. Unfortunately, to complicate things further, we have many separate instances of these database servers. For some use-cases, having 30 or more accounts is quite common. Thankfully we can set all of our passwords to be the same using a password reset utility. I think this type of configuration is quite common in some large enterprises. If Dataiku had a similar method to quickly select multiple accounts to reset the password for simultaneously, basically entering the same password for all selected accounts, that would be a huge time saver, as we have to change our passwords every 90 days. I don't think something similar is needed for shared credential connections as these are typically using database service accounts with passwords that can't be re-used, but also don't need to be reset as frequently.

[natejgardner]

Thanks @fsergot, in my case, every user has their own credentials, set in the credential manager and not in the connection settings. We don't have any exceptions to our password rules in my company, and no modern authentication methods like oauth are available, unfortunately. Even for the one database system we have in our company that supports saml authentication, MS SQL, substantial integration effort is required (it's been the full time job of a member of our admin team for nearly a year so far) to register our internal SSO system for use with DSS. But even so, for Teradata and Oracle, our company's primary database systems, we are only allowed to authenticate using passwords. Unfortunately, to complicate things further, we have many separate instances of these database servers. For some use-cases, having 30 or more accounts is quite common. Thankfully we can set all of our passwords to be the same using a password reset utility. I think this type of configuration is quite common in some large enterprises. If Dataiku had a similar method to quickly select multiple accounts to reset the password for simultaneously, basically entering the same password for all selected accounts, that would be a huge time saver, as we have to change our passwords every 90 days. I don't think something similar is needed for shared credential connections as these are typically using database service accounts with passwords that can't be re-used, but also don't need to be reset as frequently.

[Marlan]

Hi @fsergot and @natejgardner,

First of all, I now realize that what we would love to have is somewhat different than what @natejgardner is requesting.

In our case, DSS is set up to use user isolation framework. So we don't have credentials in connections. Rather each user goes to the the user center and enters credentials for each connection there.

But the same issue occurs in that a password change (which we must do quarterly) requires going into user center, credentials and updating the passwords one by one across all three of our instances. For me, this is probably about 40 credentials I need to update. Definitely not much fun.

We do use service accounts for projects deployed to our production automation instance but those passwords expire every 90 days as well.

I am not aware of our company planning to use a different approach to authenticate. I would have to research this to find out if anything like this is being planned. 

Marlan

[Marlan]

Hi @fsergot and @natejgardner,

First of all, I now realize that what we would love to have is somewhat different than what @natejgardner is requesting.

In our case, DSS is set up to use user isolation framework. So we don't have credentials in connections. Rather each user goes to the the user center and enters credentials for each connection there.

But the same issue occurs in that a password change (which we must do quarterly) requires going into user center, credentials and updating the passwords one by one across all three of our instances. For me, this is probably about 40 credentials I need to update. Definitely not much fun.

We do use service accounts for projects deployed to our production automation instance but those passwords expire every 90 days as well.

I am not aware of our company planning to use a different approach to authenticate. I would have to research this to find out if anything like this is being planned. 

Marlan

[natejgardner]

I'm pretty sure @Marlan and I have the same thing in mind, here's a mockup to clarify

Basically, every time I need to change most of my passwords at once, I'd like to be able to just select all the accounts I want to change my password for, click one edit button, type my new password once, test all the connections to make sure they worked, and then commit or cancel the change. Although the mockup only has a few connections, in practice this will save time by allowing users to update 30 or 40 passwords at once.

[natejgardner]

I'm pretty sure @Marlan and I have the same thing in mind, here's a mockup to clarify

Basically, every time I need to change most of my passwords at once, I'd like to be able to just select all the accounts I want to change my password for, click one edit button, type my new password once, test all the connections to make sure they worked, and then commit or cancel the change. Although the mockup only has a few connections, in practice this will save time by allowing users to update 30 or 40 passwords at once.

[Marlan]

Yes @natejgardner you are correct. That's exactly what we'd like to be able to do as well. Some way of defaulting the list to those which credentials entered = Yes would be great as well.

And yes agree testing to confirm password change was successful at that point would be helpful.

Thanks for creating the mockup to clarify the idea.  

Marlan

[Marlan]

Yes @natejgardner you are correct. That's exactly what we'd like to be able to do as well. Some way of defaulting the list to those which credentials entered = Yes would be great as well.

And yes agree testing to confirm password change was successful at that point would be helpful.

Thanks for creating the mockup to clarify the idea.  

Marlan

[fsergot]

Hello all,

thanks for the clarification, I now see what your idea is.

I have recorded it in our backlog

[fsergot]

Hello all,

thanks for the clarification, I now see what your idea is.

I have recorded it in our backlog

[Turribeach]

It's a sad state of afairs when outdated security policies not only causes operational inefficiencies but also weaker security. 

https://www.throttlenet.com/blog/technology-news/nist-password-guidelines-2022-challenging-tradition...

In our case we use service accounts with fixed strong passwords and keys so we are not affected by this idea. But I will be concerned if any of our user flows had so many personal credentials. In fact of the requirements to deploy a flow to our Automation server is that all connection credentials must be generic and not personal.

[Turribeach]

It's a sad state of afairs when outdated security policies not only causes operational inefficiencies but also weaker security. 

https://www.throttlenet.com/blog/technology-news/nist-password-guidelines-2022-challenging-tradition...

In our case we use service accounts with fixed strong passwords and keys so we are not affected by this idea. But I will be concerned if any of our user flows had so many personal credentials. In fact of the requirements to deploy a flow to our Automation server is that all connection credentials must be generic and not personal.