I have heard reluctance from folks in the past for having commands prompt for passwords and would certainly break the scriptability of it. We would have to add a switch that enabled the prompting for a password - if we were to add it to the credential create subcommand.
Agreed. Today as you know the credential create command prompts for a password but there is an undocumented "-value" argument that can be used. I'd stick with the same scheme where either a prompt or command line argument were possible.
This same password file is used in lots of scenarios though: KMS, javakeystore providers for key provider API, oozie, signing secret providers,e tc. I wonder whether a separate command for it would make sense.
Conceptually, yes, but aren't config values different? I'm aware of two:
- alias/AbstractJavaKeyStoreProvider: hadoop.security.credstore.java-keystore-provider.password-file
- key/JavaKeyStoreProvider: hadoop.security.keystore.java-keystore-provider.password-file
Keep in mind that we would need to do a number of things for this.
1. prompt for the password
2. persist it
3. set appropriate permissions on the file
4. somehow determine the filename to use (probably based on the password file name configuration) which would need to be provided by the user as well
5. allow for use of the same password file for multiple keystores or scenarios
6. allow for random-ish generated password without prompt
I think it's even more complicated. The user could want to use the environment variable when the credential is consumed, and so would want to provide it to the command but would not want to deal with anything file-related.
Also it's conceivable that the user could have constructed the file themselves; although this doesn't seem particularly user friendly.
So we have scenarios for hadoop credential create|list|etc that look like
- Here is the credstore password from a prompt
- Here is the credstore password on the command line
- The credstore password is already in a file in the "expected" location (set up either by hand or via your new pwdfile command).
Making a command to manage the password file makes sense. I think that we shouldn't ask the user to give it the property name though: you could modify KeyShell and CredentialShell to have a new subcommand of 'pwdfile', thusly:
- hadoop credential pwdfile [args]
- hadoop key pwdfile [args]
And they could share an implementation. This way the user does not have to remember "hadoop.security.credstore.java-keystore-provider.password-file" or the like. This also means that the provider selected needs a new interface to create said file, if applicable.
I like the auto-generate-password option for the file. I think the default would be to still prompt for the password, though. So yeah, adding a pwdfile command seems like a good idea.
The thing about the existing design that I'm going back and forth on is that the CredentialShell is high-level, and selects a provider and then simply passes information to the provider. The password is implied and not passed directly, so the CredentialShell has no notion of whether or not the underlying provider actually has a password or not.
So, for example, it would be daft of CredentialShell to accept a password on the command line if one is provided in a file, and it would also be even more daft if no password was specifed on the command line and the password wasn't in the password file either. Furthermore it would be silly to accept a password when the underlying provider does not need a password at all for proper operation (example: the UserProvider). There has to be some amount of communication between the CredentialShell and the provider in order to get the "is a password required" and "where precisely is the password" cases correct.
To make this even more interesting, in the various providers with a key store, the keyStore is either created or opened in the constructor, requiring that all the information be presented up front - without scope for the back and forth of "do you need a password and where" from the provider.
So... one way to deal with this is to move the keyStore.load() call out of the constructor and defer it until the first get/set/delete credential entry call. Then expose interfaces along the lines of "does this provider already have the password somehow?" and "set the password directly". We'd have to add default behavior in CredentialProvider (and KeyProvider) and then implement in the ones that matter.
The downside to this approach is that we move around a few error conditions. However everything can throw an IOException, so maybe this isn't a big deal. Seem reasonable? Alternative proposals?