Skip to content
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 link for Cloud deployment settings #65089

Closed
ryankeairns opened this issue May 4, 2020 · 5 comments · Fixed by #66486
Closed

Add link for Cloud deployment settings #65089

ryankeairns opened this issue May 4, 2020 · 5 comments · Fixed by #66486
Assignees
Labels
REASSIGN from Team:Core UI Deprecated label for old Core UI team

Comments

@ryankeairns
Copy link
Contributor

ryankeairns commented May 4, 2020

Relates to #56232

Describe the feature:

Provide a link for Cloud users, who sign in with SSO (i.e. admin), to easily access the deployment page for the current Kibana instance.

Describe a specific use case for the feature:

A Kibana user, who manages this deployment, needs to adjust the configuration settings. They open the Kibana navigation and click a link to open the associated deployment settings page in the Cloud UI.

Currently, this user would have to use their browser and navigate the Cloud console, sign in, and then navigate to the deployment settings page. This new link will simplify that process by linking them directly from Kibana to the associated Cloud deployment details page in a single click.


Technical considerations

  • The placement of this link in the left nav is a temporary solution until the deployment switcher is added in the new global header.
  • This link should only appear for users who are signed in with Cloud SSO. Typically, this is an administrator who then creates general users from within the Kibana UI. The latter sign in with the basic username/pw combo and should not see this link.
  • On the Kibana side, we will use the existing Cloud plugin to attain the cloudId which can be decoded into the necessary URL parts which make up the desired link URL.
  • ESS (Elastic hosted) deployments use a common root URL - cloud.elastic.co - whereas ECE (Customer hosted) deployments will have a user-defined root. We'll initially focus on the former as there is an open issue for the latter with regards to capturing that ECE root URL.

Implementation suggestion

The technical approach alluded to in the prior bullets was discussed in some detail here:
#56232 (comment)

Copy/pasted from #56232 (comment)

Kibana has the cloudId in the Cloud plugin whenever it's running in Cloud.

A cloudId is a 64bit encoded string and breaks out into <regionId?>.<provider?>.<cname>$<esClusterId>$<kibanaId>. Eg. us-east-1.aws.found.io$f0e7f777a2bb4a2cb42b142ef2f095ca$5a69c20b264a4b5dbbd71fa30bc0dca2

So in ESS creating the link is pretty simple.

cloud.elastic.co/deployments/resolve/cluster/:regionId/:esClusterId/

And that will take you to the overview page in Cloud.

In ECE the url doesn't change much we just need to replace cloud.elastic.co with the cname provided. However, the admin can change the cname and that presents a lot of challenges. I don't know if we have a good answer today for this. I'm going to try and get an answer in https://github.com/elastic/cloud/issues/54009 and circle back here. The work can start on the ESS side for now though.
ECE is a bit of a problem, going to try and get an answer in https://github.com/elastic/cloud/issues/54009

See below for some example cloudIds

ESS:

eastus2.azure.elastic-cloud.com:9243$59ef636c6917463db140321484d63cfa$a8b109c08adc43279ef48f29af1a3911
us-east-1.aws.found.io$a2a21d1fe8c33036e62fa144f7760893$76498e5ec1298d14d47560955f1ef774
us-west-1.aws.found.io$21e7851922104b0f9715fb41114afc35$7d81e1320baa47a6bbcb16e7faaeb703
us-central1.gcp.cloud.es.io$3e83fc465b934d2582175dfffd9b34a6$bac3be47a4d34732bccba675d89e9eb3

ECE:

192.168.44.10.ip.es.io:9243$38ab00fbf02446a4b9ab2cebc58e7921$d721383b0de0488caa427d5871fa9493

192.168.44.10.ip.es.io is the cname in ECE, so it's a bit hard to know exactly how to differentiate between ESS and ECE. I guess look for the region/provider structure and if you don't find it, just assume it's ECE.

Re: Starting with ESS

I would start with ESS by just basically assuming that you're in ESS always. After elastic/cloud#54009, there will probably be a new variable passed into the kibana yaml file (cloudBaseUrl or something) that you can use instead of cloud.elastic.co, but the required changes should be just a single line


Design mockup

Copy/pasted from #56232 (comment)
(If you're curious, you can also see the future header design in that comment)

cc:/ @andrew-moldovan @gjones @alexfrancoeur

@ryankeairns ryankeairns added REASSIGN from Team:Core UI Deprecated label for old Core UI team v7.9.0 v8.0.0 labels May 4, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-core-ui (Team:Core UI)

@ryankeairns ryankeairns added the release_note:skip Skip the PR/issue when compiling release notes label May 4, 2020
@ryankeairns ryankeairns removed release_note:skip Skip the PR/issue when compiling release notes v7.9.0 v8.0.0 labels May 4, 2020
@andrew-moldovan
Copy link

Looks good. I think the biggest technical question right now is around

This link should only appear for users who are signed in with Cloud SSO. Typically, this is an administrator who then creates general users from within the Kibana UI. The latter sign in with the basic username/pw combo and should not see this link.

How exactly Kibana will know this. @jowiho do you have any details on this? Will the user object contain this?

@jowiho
Copy link

jowiho commented May 5, 2020

I don't know if/how Kibana remembers how the user authenticated, through SSO or basic. Also, Kibana strictly has no way of knowing that the user singed in through Cloud SSO. It just knows that the user authenticated with a SAML realm.

However, I'm not sure if any of this really matters. A user who logged in to Kibana with a username+password can still have a valid Cloud session (existing users might continue to login in as "elastic" out of habit, or with a readonly local user because of security). And a user who logged in through Cloud SSO might not have a valid Cloud session anymore because it could have expired. So a link from Kibana to Cloud might or might not interrupt the user with a Cloud login page, regardless of how they logged in to Kibana.

@andrew-moldovan
Copy link

The original reason for only showing these links to Cloud auth'd users was around Kibana making API calls to Cloud, and possibly not having the creds for it. And we didn't want those users getting a bad experience.

However, now that we've separated out the implementation of SSO and Kibana making API calls, I agree that it probably doesn't really matter for now. Everyone can see the links and they might or might not get a Cloud login screen, which they might or might not know the creds for.

@ryankeairns
Copy link
Contributor Author

Cloud issue proposing to add links to kibana yaml: https://github.com/elastic/cloud/issues/57690

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
REASSIGN from Team:Core UI Deprecated label for old Core UI team
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants