Provider blocks, externalbrowser, token caching, mac keychain #3199
-
Using provider 0.98, config file under .snowflake/config that is configured with a single connection for each of my environments, this is assigned the ACCOUNTADMIN role. In my terraform I have 4 provider blocks, each provider using the same connection (dev) but assuming a different role, USERADMIN, ACCOUNTADMIN, SYSADMIN, SECURITYADMIN so that resources are created with the appropriate permissions and not all with accountadmin. Seems that each of these connections, is generating a token, and trying to put it into Mac keychain, so I end up putting the password in 4 or 5 times. It's a huge PITA and for sure some on the team will push back just because and want to use keys. Wondering, if there is a different way I can do this? Or how people have done it. The keychain only has the 1 token, presumably whichever one authenticated last,but since my connection is using the role accountadmin they are all the same anyways. Would be better to allow that 1 privilege connection and then switch roles in TF. If that's possible and I'm not aware, please enlighten me |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
Hey @DanielM-streetcontxt. Thanks for reaching out to us. Currently, specifying multiple provider aliases means opening a separate connection for each of them, which is why authentication is done each time. What I could suggest here would be using a different authentication type (e.g., key-pair + password). We plan to introduce a slightly different approach for the role-handling by the provider; we will consider adding an optional |
Beta Was this translation helpful? Give feedback.
Hey @DanielM-streetcontxt. Thanks for reaching out to us.
Currently, specifying multiple provider aliases means opening a separate connection for each of them, which is why authentication is done each time. What I could suggest here would be using a different authentication type (e.g., key-pair + password).
We plan to introduce a slightly different approach for the role-handling by the provider; we will consider adding an optional
use_role
(or something similar) to each resource so that a single-provider definition would be enough to provision resources using different roles. It has its challenges, though, and there is currently a way (by defining multiple providers) so it was not priorit…