Persistence and Principal Secrets

[rdsarvar]

I was starting to play around with Polaris on a local test environment and I was looking at one of the tables:

polaris_db=# select * from public.principal_secrets;
 principalclientid |            mainsecret            | principalid |         secondarysecret          | version
-------------------+----------------------------------+-------------+----------------------------------+---------
 c2c0a543bbcf0ed5  | 9280e9c6f4316143097e9d7265e34cbf |        1024 | de650b4c11bb57cd8188922177047b3b |       2
 db8d51562cd29189  | 8b0a5c742dfed4374af2b089d062ad5b |        1174 | 9aa3419b1c415314d660b171bdfbd590 |       1
(2 rows)

and noticed that principal_secrets holds in plaintext all of the principals and their secrets in plaintext.

I was curious to if this was an active design decision? For what purpose would we want to keep them as plaintext instead of hashed+salted?

[RussellSpitzer]

This is not an active decision. The original Snowflake implementation used it's own separate metastore layer, we should probably improve the eclipselink pathway for users who aren't going to implement a custom layer.

[rdsarvar]

Sounds good, should I add a placeholder issue in the project so it's at least backlogged as a consideration?

Not sure if you wanted to as you definitely have more insight into it's origins 😄 If not no problem I can start it off

[RussellSpitzer]

You are definitely welcome to, also any proposal for improvement would be welcome

[shantanu-dahiya]

Is there any documentation or guidance on how to implement one's own metastore layer?

[eric-maynard]

Hey @rdsarvar , can you take a look at #438 to see if this resolves the issue appropriately? Thanks!