LegendReusing lmaccess.id and lmaccess.key
Will LM make any steps toward encouraging or enforcing unique API tokens for different integrations/applicaitons/purposes? Currently, many of the LM datasources use lmaccess.id and lmaccess.key when API access is needed (portal metrics, okta logs, etc.).
What many other API providers do is require what they call “application registration” requiring a different set of credentials for each different use. Not only does this appeal to the more security minded, but it also makes troubleshooting easier and reduces the risk of credential expiration due to overuse.
Troubleshooting is easier because each integration/datasource/script/tool has its own set of credentials, helping identify where the cause of problems may be and limiting the blast radius of any issues.
With everything using the same set of credentials, the security profile is expanded. With the ability to reuse one set of credentials, an admin will be tempted to just give full admin rights to this credential set (even though the UI makes this more difficult, but not very hard at all). This means that the same set of RW credentials may be present in many different locations, making it easier to move laterally once one location is exploited.
Also, if everything is using the same set of creds, it’s possible there would be enough usage that the rate limiting may be enforced causing unintended behavior and/or failure.
It’s also possible that while configuring a new integration with the API credentials, if the key is fat-fingered, it could cause the token to be expired. This means that everything that uses that token will stop working until the token is reset. If the token had to be regenerated, the new token would have to be redistributed to all the applications.
