Explicitly disallow default credential file loading in repository-gcs

[rjernst]

Google cloud storage has 2 ways to authenticate: by detection of the cloud environment, or by a plaintext file containing credential information. Support for credential file is being added to the elasticsearch keystore, but the way in which the cloud environment is loaded is problematic for completely disallowing the plaintext credential file. The google code to load the default credentials first looks for an environment variable which points to the file, and then looks in "known locations", before trying to do detection of the cloud environment.

We should do just as we did with s3 and not allow using a plaintext file. One idea is to look for the environment variable and known locations, and error up front. The tricky part about this is it would require adding security permissions just to check if the env var or files exist. Another idea is to leave it as it is currently, which would both fail, due to lack of security permissions to read the env var or the file locations (in the user home directory). At minimum, we should document that this is not supported.

[dadoonet]

One idea is to look for the environment variable and known locations, and error up front.

Is it possible to catch the SMException and throw in that case a better exception?

[rjernst]

That may be possible. I will experiment.

[albertzaharovits]

Would granting permission java.io.FilePermission "<<ALL FILES>>", "read" inside the security policy file but then scoping/limiting each doPrivileged invocation inside the plugin with the appropriate least permissions be a reasonable solution? In this case, the file system permissions would be effectively granted only to the code groping for the credentials file.

In general, what do you think about forbidding (un-scopped doPriviledged) and having a least privilege method for each call site?

cc @tlrx

[rjernst]

@albertzaharovits I don't think we should add any permissions for this. Catching the security exception and "peeking" at it is one solution we might be able to use in order to give a better error message here, as suggested by @dadoonet. We should at minimum document the limitation (my last solution in the original description).

[albertzaharovits]

@rjernst understood, thanks for rephrasing it, looks more actionable now!
I was trying to provide a hustle free alternative for folks running ES on google compute by leveraging the scoped doPrivileged from Java 8.

[albertzaharovits]

This has been resurrected in today's FixItFriday. Indeed, documenting the limitation, as proposed by @rjernst is the way forward. Adding security privileges only for the sake of a friendlier run time error is not convincing anyone.

I will follow-up with the docs PR.