akerl wrote:
Granted. I hadn't considered the backlash to Linode like that. However, perhaps a more realistic solution, rather than having each script granted permission for a subset of the API, would be to sandbox an API key. For instance, API Key #1 has full access, but API Key #2 is denied access to the linode.create and linode.delete.
A "permissioning" model is the proper way to go; "this script to authorized to run functions X,Y,Z on behalf of the current linode manager logged in user". The script should never see the API key ('cos the script could obfuscatedly copy that key offsite, for later malicious use). This may require use of temporary API access keys restricted to the running linode IP address (or similar) to avoid a total rewrite of the stackscript and linode manager API model
Which comes back to my initial statement; if the existing API key is to be exposed to the stackscript then linode should make the consequences clear.
Sysadmin Barbie: Security is hard; let's go shopping.
FAQ
Search
Members
Register
Login [ Anonymous ]
