CLI tool with access to connection strings?
So, I have a normal web API with auth setup. There are different roles, and you can authenticate with a bearer token, standard stuff.
I also have a CLI tool used by system admins, that is able to use the API - it just asks the CLI user for a username/pw and authenticates with the API and saves the bearer and refresh tokens to be reused for a while.
The issue now is that I would like the CLI to be able to access some services/databases without having to go through the API. And I cannot really figure out a good/secure way of doing this. Unlike the API token, the connection strings will not expire so I do not want to save them anywhere on the CLI computer.
So what would be a good way of doing this?
My ideas (and why i dont like it) - Let the API expose the functionality that the CLI wants to perform, and just call the API instead of going directly from CLI to database/service. (I don't want to burden the API with both the extra code and the performance load that this will do) - Return the connection strings from an API endpoint, in some encrypted format that can be saved safely to disk by the CLI and reused, preferably with some sort of expiry time (i have no idea how)
My ideas (and why i dont like it) - Let the API expose the functionality that the CLI wants to perform, and just call the API instead of going directly from CLI to database/service. (I don't want to burden the API with both the extra code and the performance load that this will do) - Return the connection strings from an API endpoint, in some encrypted format that can be saved safely to disk by the CLI and reused, preferably with some sort of expiry time (i have no idea how)
16 Replies
a possible solution could be to create a separate console app with the Cocona package with a dependency to your api project. then register all your services from your api in cocona aswell
i tested it at small scale and with a few basic services and it seems to work perfectly
but dont take that as a guarantee or anything
But wouldn't that still require the connection strings to be present on all the devices that want to use the CLI?
You shouldn't put connection strings to any backend resources on client machines in any form, even encrypted. Just go through your API.
Yeah I agree, but I really dont want the extra load on the API - hence the question.
That's what the API is there for, though. To allow external consumers to call into your services and access data in a controlled way.
yes ofcourse. working alone on the project on my development machine (which was my senario) its not a problem but when shipping this to clients please do not use this as @ded said already, never ever give client applications connection strings
Again, I agree that connection strings should not be on client machines.
It seems like my question is misunderstood?
Is there no way of treating the connections the same way an api bearer token is treated? So hidden behind the login, and with a time expiry that will make it unusable after a while?
nope
bearer tokens are only safe because we can verify that the information hasnt been tampered with. but you can still view the information itself
with connection strings the whole deal is that the client cannot ever see them
that is why we have web api's
Even if you could, clients should never be allowed to directly communicate with your backend resources. As long as it is valid and in memory, it is vulnerable to exploits. Which means someone could gain access, steal valid connection information, and then misuse it.
Hmm fair enough.. This is an internal program for admins - so i thought it would be fine that they could access stuff directly, as long as the connection strings not saved on their machine.
So there is no way to move this "admin work" to the client instead of the server (api)?
Why are you so concerned with moving this work from your api / services to their machines? This seems like a lot of effort to avoid using your API for its intended purpose.
I dont wanna pay more for the API 😄
I guess i could link it up with azure accounts and allow their users to see the secrets in the keyvault. But I dont really like that either
What kind of work are these sysadmins doing that would cause a measurable increase to what you pay for your API?
Big queries / data changes stuff. But honestly I have no real measurement of what it would cost. I guess the answer is better safe than sorry, and do the work in the API
Sounds like your API wouldn't be doing much in the first place and most of the work is going to be executing sql queries.
eh that is not accurate at all - but I am convinced there is no smart way of doing what I thought about. So it will be made on API side
So thanks for the input, it was very helpful