Skip to content

Conversation

@jkakavas
Copy link
Contributor

@jkakavas jkakavas commented Apr 26, 2021

This change adds the Enroll Kibana API that allows a kibana instance to
configure itself to communicate with a secured elasticsearch cluster

This change adds the Enroll Client API that allows a client to
configure itself to communicate with a secured elasticsearch cluster
@jkakavas jkakavas added >enhancement :Security/Security Security issues without another label v8.0.0 labels Apr 26, 2021
@elasticmachine elasticmachine added the Team:Security Meta label for security team label Apr 26, 2021
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-security (Team:Security)

@jkakavas
Copy link
Contributor Author

CC @azasypkin

Copy link
Contributor

@BigPandaToo BigPandaToo left a 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

@jkakavas jkakavas requested a review from lockewritesdocs June 17, 2021 12:14
Copy link
Contributor

@BigPandaToo BigPandaToo left a 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

@jkakavas jkakavas requested a review from BigPandaToo June 18, 2021 12:36
Copy link
Contributor

@BigPandaToo BigPandaToo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Contributor

@albertzaharovits albertzaharovits left a 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.

* @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) {
Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will do, no worries

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 ?
Copy link
Contributor

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.

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());
Copy link
Contributor

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.

Copy link
Contributor Author

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

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Member

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.

Copy link
Contributor

@lockewritesdocs lockewritesdocs left a 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}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* You must have the `enroll` <<privileges-list-cluster,cluster privilege>> to use this API.

Copy link
Contributor

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.

Copy link
Contributor Author

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<1> The password for the `kibana_system` user
<1> The password for the `kibana_system` user.

@jkakavas
Copy link
Contributor Author

@albertzaharovits I've addressed your feedback but 2 points ( getCertificate vs getCertificateChain and bind vs publish address ) which need a little more discussion

@jkakavas
Copy link
Contributor Author

@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? 🙏

@jkakavas
Copy link
Contributor Author

@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.

@jkakavas jkakavas merged commit 82e7fbd into elastic:master Jun 23, 2021
@jkakavas jkakavas deleted the enroll-client-api branch June 23, 2021 19:58
jkakavas added a commit to jkakavas/elasticsearch that referenced this pull request Jul 1, 2021
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.
jkakavas added a commit that referenced this pull request Jul 8, 2021
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

>enhancement :Security/Security Security issues without another label Team:Clients Meta label for clients team Team:Security Meta label for security team v8.0.0-alpha1

Projects

None yet

Development

Successfully merging this pull request may close these issues.

10 participants