S3 Repository: Add back repository level credentials #24609
Conversation
Specifying s3 access and secret keys inside repository settings are not secure. However, until there is a way to dynamically update secure settings, this is the only way to dynamically add repositories with credentials that are not known at node startup time. This commit adds back `access_key` and `secret_key` s3 repository settings, but protects it with a required system property `allow_insecure_settings`.
dadoonet
left a comment
dadoonet
left a comment
There was a problem hiding this comment.
Left minor comments.
I think we may be need to warn when we start the node if allow_insecure_settings is set, no?
| import java.util.EnumSet; | ||
| import java.util.Set; | ||
|
|
||
| import org.elasticsearch.cluster.routing.IllegalShardRoutingStateException; |
| /** | ||
| * A setting which contains a sensitive string, but which for legacy reasons must be found outside secure settings. | ||
| * @see #secureString(String, Setting, Property...) | ||
| */ |
There was a problem hiding this comment.
Wrong name for the method?
For what purpose? Every insecure setting is automatically marked as deprecated, so simply using the setting will cause a deprecation warning. |
Ha that's right. But as it's up to the user to use that insecure setting when he registers a new repository, the admin guy who actually starts elasticsearch server might not be aware at startup time that someone else might use an insecure setting at some point. |
|
@rjernst what happens if somebody has a insecure setting but then goes and sets the property to false will the node start? And if the node has started and recovers a cluster state with such a setting will it fail? |
|
For both questions, constructing the S3Repository would fail. However, since the s3 repositories are not created within Node construction, I don't think the node will fail, just that repository would be unavailable. |
|
@rjernst LGTM then |
jasontedor
left a comment
jasontedor
left a comment
There was a problem hiding this comment.
I didn't do a full review, I just left one comment about the name of the system property. We have somewhat of a convention that we prefix these with es. that I think we should follow here.
| public abstract class SecureSetting<T> extends Setting<T> { | ||
|
|
||
| /** Determines whether legacy settings with sensitive values should be allowed. */ | ||
| private static final boolean ALLOW_INSECURE_SETTINGS = Booleans.parseBoolean(System.getProperty("allow_insecure_settings", "false")); |
There was a problem hiding this comment.
I think this should be pre-fixed with es. like we try to do with other custom system properties that we use. I'm not sure if we're 100% consistent, but we should aim to be when adding new ones.
rjernst
dismissed
jasontedor’s stale review
Ok, renamed the property as you suggested.
clintongormley
added
:Distributed Coordination/Snapshot/Restore
5 participants
Specifying s3 access and secret keys inside repository settings are not
secure. However, until there is a way to dynamically update secure
settings, this is the only way to dynamically add repositories with
credentials that are not known at node startup time. This commit adds
back
access_keyandsecret_keys3 repository settings, but protectsit with a required system property
allow_insecure_settings.