-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
Access SSL contexts using names instead of Settings #30953
Conversation
Historically we have loaded SSL objects (such as SSLContext, SSLIOSessionStrategy) by passing in the SSL settings, constructing a new SSL configuration from those settings and then looking for a cached object that matches those settings. The primary issue with this approach is that it requires a fully configured Settings object to be available any time the SSL context needs to be loaded. If the Settings include SecureSettings (such as passwords for keys or keystores) then this is not true, and the cached SSL object cannot be loaded at runtime. This commit introduces an alternative approach of naming every cached ssl configuration, so that it is possible to load the SSL context for a named configuration (such as "xpack.http.ssl"). This means that the calling code does not need to have ongoing access to the secure settings that were used to load the configuration.
Pinging @elastic/es-security |
This is mostly done, but I need to do another pass over it before reviews |
@tvernum how are we looking? Should we go ahead with reviews? |
@jaymode It's ready for review now. |
I'm going to need to think through a couple more issues on this one. As it stands, the What I think I need is to be able to apply an update to a named configuration (probably by getting the config, merging the new settings into it, and then putting that config back) |
- Prevent dynamic changes to SSL settings that also use secure settings - Dyanmically rebuild SSL context for exporters that don't use secure setting
contextName = contextName.substring(0, contextName.length() - 1); | ||
} | ||
final SSLConfiguration configuration = sslConfigurations.get(contextName); | ||
if (configuration == null && logger.isTraceEnabled()) { |
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.
derp isTraceEnabled
means the warn log message only gets logged when trace is enabled
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.
🤦♂️
*/ | ||
@Deprecated |
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 we handle this as part of this change or do you want it to be separate?
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'm planning on tackling it, it's just still being used in a few places & will require some more work.
storeSslConfiguration(key, configuration); | ||
sslContextHolders.computeIfAbsent(configuration, this::createSslContext); | ||
} | ||
}); | ||
|
||
// transport is special because we want to use a auto-generated key when there isn't one |
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 do me a favor and delete this comment? It is a left over from me that is no longer relevant
profileSettings.forEach((profileSetting) -> | ||
sslConfigurations.computeIfAbsent(new SSLConfiguration(profileSetting, transportSSLConfiguration), this::createSslContext)); | ||
return Collections.unmodifiableMap(sslConfigurations); | ||
this.sslConfigurations.put("_transport", transportSSLConfiguration); |
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 use of _
as our prefix to avoid collisions or to make something special concerns me. In the IpFilter we use .http
for HTTP to avoid collisions since it is much harder to create a setting/name that would result in that as the key. Maybe we should use .
instead of _
here?
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.
Actually I have no idea why I'm naming this one in a special way. It should just be xpack.security.transport.ssl
the only special one should be .global
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.
Scrap that, .global
should just be xpack.ssl
|
||
@ESIntegTestCase.ClusterScope(scope = Scope.SUITE, | ||
numDataNodes = 1, numClientNodes = 0, transportClientRatio = 0.0, supportsDedicatedMasters = false) | ||
public class HttpSslExporterIT extends MonitoringIntegTestCase { |
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.
this is a nit, but maybe HttpExporterSslIT
so that if someone is looking for HttpExporter
test classes, they easily find it
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 originally named it HttpExporterSslIT
but the combination of lower-case l
followed up uppercase I
offended my eyes, so I changed it. I'll switch it back.
|
||
@Override | ||
protected Settings nodeSettings(int nodeOrdinal) { | ||
if (keystore == null) { |
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.
@jkakavas is there something that should be done here for the FIPS work?
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.
Yes, thanks for catching this.
@tvernum can you please add the key and certificate files and use those instead of the keystore when setting up the MockWebServer ?
Using it for the truststore is fine, even in a FIPS-140 JVM so no additional requirements here. When I went through our tests, I opted for using the certificate for certificate_authorities
instead of the JKS for truststore
(when applicable and made sense ) mainly for consistency, but we don't have to .
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.
Oh FIPS why do you want to make my life complicated?
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 need to use the truststore
(rather than certificate_authorities
) because I need to test passwords, and PEM certs don't have passwords.
There's a few places where the usage is difficult to remove, so I'm leaving them for now and we can tackle them another time.
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.
LGTM!
if (useGlobalSSL) { | ||
connectionSettings = Settings.EMPTY; | ||
sslConfiguration = sslService.getSSLConfiguration("_global"); |
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.
_global
-> xpack.ssl
These tests were creating a SSL service that was not aware of the realm that they were trying to test. This no longer works.
Historically we have loaded SSL objects (such as SSLContext, SSLIOSessionStrategy) by passing in the SSL settings, constructing a new SSL configuration from those settings and then looking for a cached object that matches those settings. The primary issue with this approach is that it requires a fully configured Settings object to be available any time the SSL context needs to be loaded. If the Settings include SecureSettings (such as passwords for keys or keystores) then this is not true, and the cached SSL object cannot be loaded at runtime. This commit introduces an alternative approach of naming every cached ssl configuration, so that it is possible to load the SSL context for a named configuration (such as "xpack.http.ssl"). This means that the calling code does not need to have ongoing access to the secure settings that were used to load the configuration. This change also allows monitoring exporters to use SSL passwords from secure settings, however an exporter that uses a secure SSL setting (e.g. truststore.secure_password) may not have its SSL settings updated dynamically (this is prevented by a settings validator). Exporters without secure settings can continue to be defined and updated dynamically. Backport of: - c662565 - edbea73 - 6f2b7dc
* es/6.x: (24 commits) Fix broken backport Switch full-cluster-restart to new style Requests (#32140) Fix multi level nested sort (#32204) MINOR: Remove unused `IndexDynamicSettings` (#32237) (#32248) [Tests] Remove QueryStringQueryBuilderTests#toQuery class assertions (#32236) Switch rolling restart to new style Requests (#32147) Enhance Parent circuit breaker error message (#32056) [ML] Use default request durability for .ml-state index (#32233) Enable testing in FIPS140 JVM (#31666) (#32231) Remove indices stats timeout from monitoring docs TESTS: Check for Netty resource leaks (#31861) (#32225) Rename ranking evaluation response section (#32166) Dependencies: Upgrade to joda time 2.10 (#32160) Backport SSL context names (#30953) to 6.x (#32223) Require Gradle 4.9 as minimum version (#32200) Detect old trial licenses and mimic behaviour (#32209) Painless: Simplify Naming in Lookup Package (#32177) add support for write index resolution when creating/updating documents (#31520) A replica can be promoted and started in one cluster state update (#32042) Rest test - allow for snapshots to take 0 milliseconds ...
Historically we have loaded SSL objects (such as SSLContext,
SSLIOSessionStrategy) by passing in the SSL settings, constructing a
new SSL configuration from those settings and then looking for a
cached object that matches those settings.
The primary issue with this approach is that it requires a fully
configured Settings object to be available any time the SSL context
needs to be loaded. If the Settings include SecureSettings (such as
passwords for keys or keystores) then this is not true, and the cached
SSL object cannot be loaded at runtime.
This commit introduces an alternative approach of naming every cached
ssl configuration, so that it is possible to load the SSL context for
a named configuration (such as "xpack.http.ssl"). This means that the
calling code does not need to have ongoing access to the secure
settings that were used to load the configuration.
Resolves: #30344