Help understanding the login deprecation warning

[samwmarsh]

Hey, I've noticed that 4 months ago on the sc.login endpoint, a deprecation warning was added - https://github.com/tenable/pyTenable/pull/832/files#diff-feabad784b4add9fef30cdc2460da4b6a5dd588207578344188ab56fa473a5d7R339

I can't see reference to this in the current tenable.sc API documentation, and it is also possible to generate API tokens via the API using username/password auth. I'm trying to understand why this endpoint is being deprecated as I believe this actually reduces security in our case. We use LDAP (AD backed) users to login, and as such are able to cycle the credential on a frequent cadence. If we are forced to store a static API key, we're going to be more exposed to exposure. Please could you help us understand why this deprecation warning has been added, what the logic is behind removing username/password auth, and if there's going to be an additional endpoint to get an API token using username/password rather than having to use static keys.

I believe this is a pyTenable question rather than a Tenable case but happy to be told otherwise.

Thanks!
Sam

[SteveMcGrath]

API keys would actually have a lower exposure footprint, and also are significantly less problematic.

• API Keys can be managed and rolled independently of username & password. This means you can reset keys way more frequently if you need, or even write a script to programmatically roll them on a schedule.
• API Keys don't suffer the problematic session limits that Username & password do
• API keys are stateless, and don't suffer from session lifetime limits
• Since API Keys introduction in SC 5.12 Tenable has pushed all new integrations to API Keys instead of session auth
• Session Auth also forces the same session management functions to be run on every call, which was never designed for the call speed of programmatic interaction. API Keys however run through a much lighter-weight auth system that is designed to handler the higher API call loads.

The decision to start deprecation of the session auth within pytenable was after API keys have coexisted with session auth for several years now, and have proven themselves to have significant performance benefits and sidestep a lot of problematic support issues that stemmed from environmental session management configurations that were incompatible with integrations.

Tenable largely made the decision some time ago to support API Keys as the primary auth mechanism in favor of username/password a few years ago, and the pyTenable project is simply playing catchup and signaling to the user-base what Tenable holistically has been doing for some time.

This also better aligns to the rest of the codebase within pyTenable and directionally aligns the codebase.

Hope this helps to explain the positioning here. in short, Username/Password was something that likely should have been deprecated some time ago, however got lost in the shuffle.

[samwmarsh]

Hey @SteveMcGrath ,

Thanks for that explanation, I guess given that API keys can be rolled programmatically and don't suffer session limits, is there scope to add this as part of the pyTenable library? We find it extremely helpful to be able to auth via username/password and grab a token, so if we could provide pyTenable with a username/password and the API key roll was performed in the background, and then used within the SC session, that would be perfect. Ideally we wouldn't manage this outside of pyTenable within another script.

Thanks,
Sam

[SteveMcGrath]

I would recommend avoiding user/pass altogether. You can generate an initial keyset in SC by following this guide.

API Keys can be stored as environment variables (TSC_ACCESS_KEY, TSC_SECRET_KEY) so that they aren't stored in any script. pyTenable will pick those up and use them without needing to pass them in. I have noticed that we never wrapped the api key generation api endpoint, which will note on this issue to include in the next release.

[samwmarsh]

Ah that sounds good, I think if we get to a point where we can have a stored access/secret key in a secret manager our end, pull that to env vars, hit the api generation key (which will delete the old ones and provide new ones) and store them back in our secret manager, that should do the trick. I'll look to move this over in our scripts once the endpoint is available in the next release. Thanks for taking the time to go through this!

[SteveMcGrath]

We can add the endpoint to handle consuming a new API key, but wiring that to your secrets manager would be on you guys.

For reference, in my local dev environment I use 1password + chezmoi to manage my dotfiles. I ahve the following envvars exposed TSC_URL, TSC_ACCESS_KEY, and TSC_SECRET_KEY. having all of those allows me to call SC like this:

from tenable.sc import TenableSC
tsc = TenableSC()

I also noted ion the docs that the envvars arent clearly laid out in SC either (likely as a lot of the docs just are that old). I'll add that as well.

[samwmarsh]

Yep sorry, to be clear that secret storage would be on us, just the rolling of the API tokens to exist with pyTenable.

We also use chezmoi with our dotfiles! 😄

[SteveMcGrath]

Looks like an added wrinkle to help facilitate this move is that SC 6.5 appears to changed how Session auth works in a potentially breaking way.