Support for multiple keys within 'accessKey' option
asilvas opened this issue · comments
This feature is a replacement for existing "accessKey" option (though "accessKey" will automatically be converted for backward compatibility). This feature allows:
- Multiple keys to enabled
- Optionally keys to be restricted to certain commands (you may want to leverage local-specific keys for high-risk commands and shared keys for publically accessible remote commands).
fyi @azweb76
Example usages:
Same as using accessKey today:
accessKey: "myLocalKey"
Expose a shared key for select commands:
accessKey: "myLocalKey;mySharedKey[health,info]"
Expose a key with black-listed commands:
accessKey: "mySharedKey[health:disabled,info:disabled]"
Expose a shared key and override default access to ensure remote accessibility:
accessKey: "myLocalKey;mySharedKey[health:remote,info:remote,restart:remote]" } }
@asilvas @azweb76 I'm a bit on the fence in regards to keys. They sound good in theory, but the assumption is that a brute force attack would never happen. I could easily break any key needed by cluster-service in a matter of seconds. This is another example IMO where we're adding way too many features to a codebase that needs more clarity and simplicity.
Remote access really isn't attractive to me. If I need statistics, then I can author a server that only exposes the commands I need to obtain them. Otherwise, local access is fine.
I'll say one last thing about keys, they would have a benefit in preventing accidents, like unwanted shutdown. They most certainly do not add security without handling brute force attacks.
It's no different than hitting any other API with a private key. It isn't intended to be a high-security feature, which is why commands are restricted based on their risk (in proc, local, or remote). Currently the most common "remote" use case is simply a "health" check.
There's plenty of room for improvements, no doubt.
Code checked in, but undocumented feature until it gets some usage.