-
Notifications
You must be signed in to change notification settings - Fork 24.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include realm type in Security Realm setting keys #30241
Conversation
This moves all Realm settings to an Affix definition. However, because different realm types define different settings (potentially conflicting settings) this requires that the realm type become part of the setting key. Thus, we now need to define realm settings as: xpack.security.authc.realms: file.file1: order: 0 native.native1: order: 1
Pinging @elastic/es-security |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the direction this is going and would like to see if we can address the todos and get this incorporated
|
||
@Override | ||
public String toString() { | ||
return type + '.' + name; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm should we be consistent between this and Realm#toString
?
} | ||
|
||
public static class RealmIdentifier { | ||
final String type; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe we should just make these values private and use the getters?
/** | ||
* TODO REALM-SETTINGS[TIM] This java doc is completely wrong now |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's make sure we address this :)
public Collection<? extends Setting<?>> getAllSettings() { | ||
return allSettings; | ||
/*** | ||
* TODO: this is horrible |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you elaborate?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the comment must have been for a previous version of that method. The current implementation isn't pretty, but it's no longer horrible.
@@ -548,6 +549,7 @@ static Settings additionalSettings(final Settings settings, final boolean enable | |||
return settingsList; | |||
} | |||
|
|||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: unnecessary line
@@ -111,11 +111,14 @@ static boolean isStandardRealm(String type) { | |||
private InternalRealms() { | |||
} | |||
|
|||
/** | |||
* TODO REALM-SETTINGS[TIM] This can be redone a lot now the realm settings are keyed by type |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we go ahead and redo this here?
@@ -453,7 +453,9 @@ protected void doRun() throws Exception { | |||
public void onFailure(Exception e) { | |||
IOUtils.closeWhileHandlingException(searchConnection); | |||
listener.onFailure(e); | |||
}; | |||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unnecessary change
@tvernum what's the state of this? Please let me know if you're ready for review again. |
return globalSettings().getByPrefix(sslPrefix); | ||
} | ||
|
||
public static class RealmIdentifier { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you add javadocs about this class?
x-pack/plugin/core/src/main/java/org/elasticsearch/xpack/core/security/authc/RealmConfig.java
Show resolved
Hide resolved
final Map<String, Set<Setting<?>>> childSettings = getSettingsByRealm(extensions); | ||
childSettings.forEach(RealmSettings::verify); | ||
return validator(childSettings); | ||
public static Settings get(Settings settings) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The method name here is a bit ambiguous to me; maybe extract
or something?
} | ||
|
||
public static Set<Setting.AffixSetting<?>> getSettings(String realmType) { | ||
return Sets.newHashSet( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
use Stream.of
instead of Sets.newHashSet
.build(); | ||
} else { | ||
cache = null; | ||
} | ||
} | ||
|
||
private <T> T setting(Function<String, Setting.AffixSetting<T>> settingFunction) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you add javadocs for this method
@@ -323,6 +324,17 @@ public static void addSecureSettings(Settings.Builder builder, Consumer<MockSecu | |||
} | |||
} | |||
|
|||
public static <T> String getSettingKey(Function<String, Setting.AffixSetting<T>> settingFactory, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
add javadocs for these methods
I've picked this up again and want to take this quiet period between 6.4 changes and 6.5 changes to get it merged. I've just brought it back up to date with master, and will tackle outstanding review comments. |
To close this out, I've now raised PRs for all the refactors I want to get done on this on master. I may still raise a change for 6.x to backport a few of the new methods from |
We changed the way realm settings are defined, and this affects custom realms in SecurityExtensions. This change adds those details to the breaking changes docs. Relates: #30241
Many realm tests were written to use separate setting objects for "global settings" and "realm settings". Since #30241 there is no distinction between these settings, so these tests can be cleaned up to use a single Settings object.
This removes an obsolete constructor that was still being called from some tests. Relates: elastic#30241
In elastic#30241 Realm settings were changed, but the Kerberos realm settings were not registered correctly. This change fixes the registration of those Kerberos settings. Also adds a new integration test that ensures every internal realm can be configured in a test cluster. Also fixes the QA test for kerberos. Resolves: elastic#35942
In #30241 Realm settings were changed, but the Kerberos realm settings were not registered correctly. This change fixes the registration of those Kerberos settings. Also adds a new integration test that ensures every internal realm can be configured in a test cluster. Also fixes the QA test for kerberos. Resolves: #35942
Realm settings were changed in elastic#30241 in a non-BWC way. If you try and start a 7.x node, using a 6.x config style, then the default error messages do not adquately describe the cause of the problem or the solution. This change detects the when realms are using the 6.x style and fails with a specific error message. This detection is a best-effort, and will detect issues when the realms have not be modified to use the 7.x style, but may not detect situations where the configuration was partially changed. e.g. We can detect this: xpack.security.authc: realms.pki1.type: pki realms.pki1.order: 3 realms.pki1.ssl.certificate_authorities: [ "ca.crt" ] But this (where the "order" has been updated, but the "ssl.*" has not) will fall back to the standard "unknown setting" check xpack.security.authc: realms.pki.pki1.order: 3 realms.pki1.ssl.certificate_authorities: [ "ca.crt" ] Closes: elastic#36026
Realm settings were changed in #30241 in a non-BWC way. If you try and start a 7.x node using a 6.x config style, then the default error messages do not adequately describe the cause of the problem, or the solution. This change detects the when realms are using the 6.x style and fails with a specific error message. This detection is a best-effort, and will detect issues when the realms have not been modified to use the 7.x style, but may not detect situations where the configuration was partially changed. e.g. We can detect this: xpack.security.authc: realms.pki1.type: pki realms.pki1.order: 3 realms.pki1.ssl.certificate_authorities: [ "ca.crt" ] But this (where the "order" has been updated, but the "ssl.*" has not) will fall back to the standard "unknown setting" check xpack.security.authc: realms.pki.pki1.order: 3 realms.pki1.ssl.certificate_authorities: [ "ca.crt" ] Closes: #36026
As part of elastic#30241 realm settings were changed to be true affix settings. In the process of this change, the "ssl." prefix was lost from the realm truststore password. It should be: xpack.security.authc.realms.<type>.<name>.ssl.truststore.password Due to a mismatch between the way we define SSL settings and load SSL contexts, there was no way to define this legacy password setting in a realm config. The settings validation would reject "ssl.truststore.password" but the SSL service would ignore "truststore.password" Resolves: elastic#41663
As part of #30241 realm settings were changed to be true affix settings. In the process of this change, the "ssl." prefix was lost from the realm truststore password. It should be: xpack.security.authc.realms.<type>.<name>.ssl.truststore.password Due to a mismatch between the way we define SSL settings and load SSL contexts, there was no way to define this legacy password setting in a realm config. The settings validation would reject "ssl.truststore.password" but the SSL service would ignore "truststore.password" Resolves: #41663
As part of elastic#30241 realm settings were changed to be true affix settings. In the process of this change, the "ssl." prefix was lost from the realm truststore password. It should be: xpack.security.authc.realms.<type>.<name>.ssl.truststore.password Due to a mismatch between the way we define SSL settings and load SSL contexts, there was no way to define this legacy password setting in a realm config. The settings validation would reject "ssl.truststore.password" but the SSL service would ignore "truststore.password" Resolves: elastic#41663 Backport of: elastic#42336
As part of elastic#30241 realm settings were changed to be true affix settings. In the process of this change, the "ssl." prefix was lost from the realm truststore password. It should be: xpack.security.authc.realms.<type>.<name>.ssl.truststore.password Due to a mismatch between the way we define SSL settings and load SSL contexts, there was no way to define this legacy password setting in a realm config. The settings validation would reject "ssl.truststore.password" but the SSL service would ignore "truststore.password" Resolves: elastic#41663 Backport of: elastic#42336
As part of #30241 realm settings were changed to be true affix settings. In the process of this change, the "ssl." prefix was lost from the realm truststore password. It should be: xpack.security.authc.realms.<type>.<name>.ssl.truststore.password Due to a mismatch between the way we define SSL settings and load SSL contexts, there was no way to define this legacy password setting in a realm config. The settings validation would reject "ssl.truststore.password" but the SSL service would ignore "truststore.password" Backport of: #42336
As part of #30241 realm settings were changed to be true affix settings. In the process of this change, the "ssl." prefix was lost from the realm truststore password. It should be: xpack.security.authc.realms.<type>.<name>.ssl.truststore.password Due to a mismatch between the way we define SSL settings and load SSL contexts, there was no way to define this legacy password setting in a realm config. The settings validation would reject "ssl.truststore.password" but the SSL service would ignore "truststore.password" Backport of: #42336
As part of elastic#30241 realm settings were changed to be true affix settings. In the process of this change, the "ssl." prefix was lost from the realm truststore password. It should be: xpack.security.authc.realms.<type>.<name>.ssl.truststore.password Due to a mismatch between the way we define SSL settings and load SSL contexts, there was no way to define this legacy password setting in a realm config. The settings validation would reject "ssl.truststore.password" but the SSL service would ignore "truststore.password" Resolves: elastic#41663
This moves all Realm settings to an Affix definition.
However, because different realm types define different settings
(potentially conflicting settings) this requires that the realm type
become part of the setting key.
Thus, we now need to define realm settings as: