-
Notifications
You must be signed in to change notification settings - Fork 25.6k
Add the Enroll Kibana API #72207
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
Add the Enroll Kibana API #72207
Conversation
This change adds the Enroll Client API that allows a client to configure itself to communicate with a secured elasticsearch cluster
|
Pinging @elastic/es-security (Team:Security) |
|
CC @azasypkin |
.../core/src/main/java/org/elasticsearch/xpack/core/action/TransportClientEnrollmentAction.java
Outdated
Show resolved
Hide resolved
client/rest-high-level/src/main/java/org/elasticsearch/client/ClusterClient.java
Outdated
Show resolved
Hide resolved
rest-api-spec/src/main/resources/rest-api-spec/api/security.enroll_client.json
Outdated
Show resolved
Hide resolved
rest-api-spec/src/main/resources/rest-api-spec/api/security.enroll_client.json
Show resolved
Hide resolved
BigPandaToo
left a comment
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.
Added few comments, mostly nit. Feel free to merge after you addressing them
client/rest-high-level/src/main/java/org/elasticsearch/client/ClusterRequestConverters.java
Outdated
Show resolved
Hide resolved
client/rest-high-level/src/test/java/org/elasticsearch/client/ClusterClientIT.java
Outdated
Show resolved
Hide resolved
x-pack/plugin/core/src/main/java/org/elasticsearch/xpack/core/XPackPlugin.java
Show resolved
Hide resolved
...ain/java/org/elasticsearch/xpack/core/security/action/enrollment/ClientEnrollmentAction.java
Outdated
Show resolved
Hide resolved
...java/org/elasticsearch/xpack/security/action/enrollment/TransportClientEnrollmentAction.java
Outdated
Show resolved
Hide resolved
BigPandaToo
left a comment
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.
Left few comments and suggestions
client/rest-high-level/src/main/java/org/elasticsearch/client/SecurityClient.java
Outdated
Show resolved
Hide resolved
...rest-high-level/src/main/java/org/elasticsearch/client/security/KibanaEnrollmentRequest.java
Show resolved
Hide resolved
...t/rest-high-level/src/main/java/org/elasticsearch/client/security/NodeEnrollmentRequest.java
Show resolved
Hide resolved
client/rest-high-level/src/test/java/org/elasticsearch/client/SecurityIT.java
Show resolved
Hide resolved
client/rest-high-level/src/test/java/org/elasticsearch/client/SecurityIT.java
Outdated
Show resolved
Hide resolved
...java/org/elasticsearch/xpack/security/action/enrollment/TransportKibanaEnrollmentAction.java
Outdated
Show resolved
Hide resolved
...java/org/elasticsearch/xpack/security/action/enrollment/TransportKibanaEnrollmentAction.java
Outdated
Show resolved
Hide resolved
...java/org/elasticsearch/xpack/security/action/enrollment/TransportKibanaEnrollmentAction.java
Outdated
Show resolved
Hide resolved
...java/org/elasticsearch/xpack/security/action/enrollment/TransportKibanaEnrollmentAction.java
Outdated
Show resolved
Hide resolved
...org/elasticsearch/xpack/security/action/enrollment/TransportKibanaEnrollmentActionTests.java
Outdated
Show resolved
Hide resolved
...java/org/elasticsearch/xpack/security/action/enrollment/TransportKibanaEnrollmentAction.java
Outdated
Show resolved
Hide resolved
BigPandaToo
left a comment
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
albertzaharovits
left a comment
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've left a couple of points. They need to be addressed before merging.
Nonetheless I have approved. Do ping me if there's anything I should clarify.
...igh-level/src/test/java/org/elasticsearch/client/security/ClientErnollmentResponseTests.java
Outdated
Show resolved
Hide resolved
x-pack/plugin/core/src/main/java/org/elasticsearch/xpack/core/ssl/StoreKeyConfig.java
Show resolved
Hide resolved
| * @param settings the node's settings | ||
| * @param licenseState the license state that will be used to determine if security is licensed | ||
| */ | ||
| public RestKibanaEnrollmentAction(Settings settings, XPackLicenseState licenseState) { |
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.
Only if it is irking you as well, I would prefer using Enroll rather than Enrollment, when possible.
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.
will do, no worries
...java/org/elasticsearch/xpack/security/action/enrollment/TransportKibanaEnrollmentAction.java
Outdated
Show resolved
Hide resolved
| ActionFilters actionFilters) { | ||
| super(KibanaEnrollmentAction.NAME, transportService, actionFilters, KibanaEnrollmentRequest::new); | ||
| this.environment = environment; | ||
| // Should we use a specific origin for this ? Are we satisfied with the auditability of the change password request as-is ? |
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 personally prefer a different origin, but this is by no means something I would hold this PR for. We've been very lax about origins.
...java/org/elasticsearch/xpack/security/action/enrollment/TransportKibanaEnrollmentAction.java
Outdated
Show resolved
Hide resolved
...java/org/elasticsearch/xpack/security/action/enrollment/TransportKibanaEnrollmentAction.java
Outdated
Show resolved
Hide resolved
| client.execute(NodesInfoAction.INSTANCE, nodesInfoRequest, ActionListener.wrap(nodesInfoResponse -> { | ||
| final List<String> nodeList = new ArrayList<>(); | ||
| for (NodeInfo nodeInfo : nodesInfoResponse.getNodes()) { | ||
| nodeList.add(nodeInfo.getInfo(HttpInfo.class).getAddress().publishAddress().toString()); |
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.
Publish address only exposes a single address (per node). Hopefully the one reachable from Kibana (but no way to tell for sure).
It is safer to show all the addresses, but that is not possible if we must also support binding to 0.0.0.0 (ie instead of showing publish addresses we can show bind addresses, but bind can be 0.0.0.0 which is not routable).
So there is no perfect solution. I would choose to show bind addresses because the setup script won't use 0.0.0.0. Your call.
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.
Good catch. I didn't think this through as much as I should have
I would choose to show bind addresses because the setup script won't use 0.0.0.0
The only problem with this is docker where we bind on 0.0.0.0 actually. I 'll think this through on Monday and get back with a suggestion
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.
Thought this through a little more:
- Kibana already can communicate with an ES node ( it just sent us a request ). The idea here is that we return the http addresses for other nodes so that it might connect to other nodes if it wants/needs.
- bind_address is always 0.0.0.0 in docker
I think publish_address is an appropriate compromise for this. We can, however, get bind_address and return those unless it is 0.0.0.0, when we would fallback to publish_address.
@azasypkin , @legrego ping for visibility and feedback.
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.
It sounds like publish address is what we would want here. While there are no guarantees that Kibana will be able to reach ES at that address, the docs claim that the publish address must be reachable by all clients (if I understand correctly).
I'm not opposed to also including the bind address in the response if it's not 0.0.0.0, however.
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.
Same here, returning of publish_address or publish_address + bind_address[] (excluding 0.0.0.0) sounds like a reasonable approach to me.
lockewritesdocs
left a comment
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.
Added some suggestions for updates to the Enroll Kibana API doc page.
|
|
||
| [[security-api-kibana-enrollment-prereqs]] | ||
| ==== {api-prereq-title} | ||
|
|
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.
| * You must have the `enroll` <<privileges-list-cluster,cluster privilege>> to use this API. |
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 that this privilege is the same as the enroll node API.
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.
We are not adding the named privilege after all, but thanks this reminds me to remove the reference from the enroll node API !
| ] | ||
| } | ||
| -------------------------------------------------- | ||
| <1> The password for the `kibana_system` user |
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.
| <1> The password for the `kibana_system` user | |
| <1> The password for the `kibana_system` user. |
...curity/src/test/resources/org/elasticsearch/xpack/security/action/enrollment/README.asciidoc
Outdated
Show resolved
Hide resolved
|
@albertzaharovits I've addressed your feedback but 2 points ( getCertificate vs getCertificateChain and bind vs publish address ) which need a little more discussion |
|
@albertzaharovits do you want to take another look please and see if something needs to be resolved/discussed more or we should move forward with merging this? 🙏 |
We went through remaining points in a zoom. |
StoreKeyConfig#x509Certificates was introduced in elastic#72207 in order to retrieve all certificates from the keystore used for HTTP TLS and then filter out to get the CA certificate. Since we explicitly add the CA key/cert as a PrivateKeyEntry on startup, we can iterate on the PrivateKeyEntry objects instead.
StoreKeyConfig#x509Certificates was introduced in #72207 in order to retrieve all certificates from the keystore used for HTTP TLS and then filter out to get the CA certificate. Since we explicitly add the CA key/cert as a PrivateKeyEntry on startup, we can iterate on the PrivateKeyEntry objects instead.
This change adds the Enroll Kibana API that allows a kibana instance to
configure itself to communicate with a secured elasticsearch cluster