Adding RBAC to new Cloud links

[alexfrancoeur]

As part of the Getting Started work (#94207), @ryankeairns and the team have added support for linking back to Cloud. This is a huge milestone to providing a seamless experience between our Cloud console and Kibana. This work has been merged and I believe we are targeting supporting them in 7.13 (#66486, #86394, https://github.com/elastic/cloud/issues/57690, #93436)

It's recently come to my attention that we do not have any RBAC or feature controls as part of this implementation. Meaning, whether it's a new deployment or an upgrade, every user entering Kibana, regardless of roles and permissions will see these new links back to Cloud (Manage this deployment, Profile and Account & Billing ).

At the moment, only a small amount of users could / should have access to Cloud console who are using Kibana as a hosted service. And unfortunately, we are not at the point where we can map roles between Cloud and Kibana. The unified security work will eventually resolve this, but that's a bit further out.

Proposal

I don't think we can move forward with these links back in their current omni-present state. I think we'll need RBAC for these links if we want to go live with them, or at the very least, provide a way to disable them. With FF around the corner, I'm not sure these changes will make it in time for 7.13, but here's a short term proposal and I'd love to hear what other folks think about this.

• If adding RBAC on these components is not trivial, remove the current functionality or hide behind a feature flag for 7.13
• Since there is no role mapping between Cloud and Kibana, our best bet is likely to only show the Manage this deployment, Profile and Account & Billing links to the superuser role. I believe this role is the default for the first run experience / Cloud administrator, but I may be wrong.
• If you are a not a superuser and Cloud hosted, we remove the Manage this deployment and Account & Billing and likely revert to the self managed experience to support SSO, Basic Auth and other non-Cloud authentication mechanisms

There's plenty of opportunity to add more granular feature controls, etc. but I'm not sure this is necessary for the first iteration.

Link examples

Manage this deployment

Profile and Account & Billing with Cloud links

Profile link for self managed

cc: @VijayDoshi @ryankeairns @gjones @johnbarrierwilson @osmanis @legrego @kobelb @joshdover @alexh97

[elasticmachine]

Pinging @elastic/kibana-design (Team:Kibana-Design)

[elasticmachine]

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

[elasticmachine]

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

[legrego]

Thanks for opening this issue Alex --

If adding RBAC on these components is not trivial, remove the current functionality or hide behind a feature flag for 7.13

Kibana doesn't have any way of knowing if the current user is authorized for Cloud resources, so unless Cloud already has a way to expose this via API, then I suspect this will be non-trivial.

We might be able to infer if the current user authenticated via Cloud SSO, but this would be a very brittle check, and it also won't account for the evolving cloud user model.

Since there is no role mapping between Cloud and Kibana, our best bet is likely to only show the Manage this deployment, Profile and Account & Billing links to the superuser role. I believe this role is the default for the first run experience / Cloud administrator, but I may be wrong.

Currently, cloud administrators are superusers by default (this will change), but not all superusers are cloud administrators. If we only check against the superuser role, then we will end up showing these cloud links to users who are not authorized to use them.

Given this, my vote is to hide this behind a feature flag or revert the current functionality, unless cloud has an API readily available for us to consume.

[kobelb]

Given this, my vote is to hide this behind a feature flag or revert the current functionality, unless cloud has an API readily available for us to consume.

+1

[alexfrancoeur]

We can dive, but I don't believe we'll have the ability to make a request to Cloud any time soon (cc: @rarichard )

Currently, cloud administrators are superusers by default (this will change), but not all superusers are cloud administrators. If we only check against the superuser role, then we will end up showing these cloud links to users who are not authorized to use them.

I would think that in a production cluster superusers are few and far between. And as you pointed our @legrego , it's probably a safe assumption that a Cloud administrator or a trial user is a superuser today. (Am I correct in assuming this change is further out?)

If only a handful of Kibana administrators see these links and cannot access the underlying content when they exit Kibana, I think I'd be fine with that if we felt there was enough value in providing this seamless navigation to trial users and Cloud administrators. Through that lens, it feels like this may be a product decision we need to make. If we decided we we're OK with that, is this a reasonably small scope? And is there any security vulnerability in showing these links to folks that may not be authorized to access?

[legrego]

I would think that in a production cluster superusers are few and far between. And as you pointed our @legrego , it's probably a safe assumption that a Cloud administrator or a trial user is a superuser today. (Am I correct in assuming this change is further out?)

Yes, this change is further out - we don't have a firm timeframe for this yet.

If we decided we we're OK with that, is this a reasonably small scope?

Yes, checking if the current user has the superuser role is fairly easy for us to do. That said, the @elastic/kibana-security team might not have capacity to take this on prior to feature freeze. If we think this is acceptable to treat as a bug that we fix after feature freeze but before launch, then that would buy us more time.

And is there any security vulnerability in showing these links to folks that may not be authorized to access?

I wouldn't expect any, unless the deployment id itself is considered sensitive information.

If only a handful of Kibana administrators see these links and cannot access the underlying content when they exit Kibana, I think I'd be fine with that if we felt there was enough value in providing this seamless navigation to trial users and Cloud administrators. Through that lens, it feels like this may be a product decision we need to make.

My preference to hide/remove still stands, but I'll happily defer to the product team to make the final decision. If we do move forward with the superuser-only approach, then it would be good to understand what the user flow looks like for superusers who are not cloud administrators. Do they ultimately land on the Cloud Console login page when clicking these links?

[alexfrancoeur]

I plan to sync up with @VijayDoshi on this later today around the importance of linking back to Cloud for the Getting Started initiative. My gut tells me it's relatively important and potentially critical soon. Given that FF is today, we'll likely need to resolve this through a bug fix before release. Whether that is hiding, removing or introducing RBAC to the links.

The way I see it, Cloud role mapping and even being able to call Cloud API's (https://github.com/elastic/cloud/issues/67400) are further out. With standby instances becoming a focus for the Cloud engineering team, we'll need a way to link back to Cloud Console as new trials may not even see it upon signing up.

If we can introduce RBAC as a way to resolve this bug, and assuming it is important for GS, here's my proposal for 7.13.

• Add RBAC on these links for the superuser role, accepting the current limitations
• Solidify timelines for Cloud role mapping and / or API to determine Cloud role, with new or existing issues to track.
• Open new issue to discuss feature controls for these links

If we determine this as a priority, are we able to introduce RBAC on these links after FF? I'll follow up on this thread later today.

it would be good to understand what the user flow looks like for superusers who are not cloud administrators

Yes, I believe that would be the case. We would send users with the superuser role to Cloud but they essentially will not have access.

[alexfrancoeur]

Quick update, after Vijay and I spoke, we both agree on the proposal listed above from a product perspective. If we cannot add RBAC in 7.13, we'd prefer to hide / remove the functionality for now and introduce RBAC in the next release.

@legrego @kobelb fully understanding the preference to have a complete solution, what are your thoughts on the proposal listed above. Do you think RBAC can be introduced in 7.13?

[kobelb]

@alexfrancoeur from my perspective, it's a bug that we are always showing the Cloud links. As a result, as long as the bugfix is safe, we can merge it post feature-freeze. I'll have to defer to Larry on the practical timelines to fix the bug.

When I log into a 7.12 instance in ESS, I'm not seeing the customized account profile that was added in #82803 and shipped as part of 7.11. This makes me suscept that Cloud isn't setting the following settings in the kibana.yml:

xpack.cloud.resetPasswordUrl: 'https://cloud.elastic.co/user/settings' # Cloud profile link
xpack.cloud.accountUrl: 'https://cloud.elastic.co/account/activity' # Account link

I'm assuming that we have plans for Cloud to configure these settings sometime soon that would apply to 7.10 through 7.13? Otherwise, the bugfix we're planning to make won't have any effect and we could potentially push this work to ship in 7.14.

[alexfrancoeur]

I'l defer to @ryankeairns on the details, but I believe this will be coming in 7.13. Here's the rough timeline from my perspective.

1. In 7.9(?) we added this PR and reverted / hid because there was no Cloud support: Adds link for Cloud deployment settings #66486
2. We updated the UI (text and icons) to match Clouds Update text and icons to align with Cloud #86394
3. Cloud added the deployment links to kibana.yml https://github.com/elastic/cloud/issues/57690
4. We then updated the links to handle the new URLs Update Cloud plugin to handle new URLs  #93436

I'm waiting for 7.13 BC1 to be available so we can test on Cloud, but I imagine we tested to ensure this worked already.

We have two options to fix the bug. Either remove / hide the functionality, or add RBAC on the links (which is what we plan to do until there is a better way to determine Cloud roles)

[ryankeairns]

That's the correct timeline. Nothing would have been displayed until now, in 7.13. The early solution was on the Kibana side only and relied upon proposed links that, in the end (now), changed.

[kobelb]

Cool, thanks for the clarification @alexfrancoeur and @ryankeairns.

[alexfrancoeur]

@legrego let us know what you think about practical timelines for a backport / fix for this bug. Worse case scenario, we remove / hide and re-add for 7.14.

[legrego]

@alexfrancoeur I'm hoping to have a PR up by the end of the week, but I'll keep this issue updated with my progress either way

[alexfrancoeur]

Thank you so much @legrego ! 💪

[legrego]

PR is up and approved -- should be merged today barring any unforeseen CI issues: #97870

[ryankeairns]

Wow, thanks so much @legrego !

[alexfrancoeur]

Cloud staging screenshot:

Thank you so much @legrego!