Security Enhancements ( RBAC, identity etc )

[spunkedy]

I just got permission to be able to contribute to this project.

I have fallen in love with livebook, and have started encouraging it's use quite a bit at my work.

I am trying to use this in a high security environment. I am currently able to deploy this with helm behind cloudflare zerotrust with it auto loading the LB_ secrets injected from vault.

To make the security use case easy, these features would be great:

• Identity
• Audit trail of identity of what actions were taken
• App only execution role
• AWS identiy via oidc capable
• Additional docker targets for locked down images? base off of something like

If any of these things are desirable for this project, I don't mind creating pull requests for the desired implementation.

Identity Claims

I was looking through the code base, and the user_plug

• Could make it simple and just allow a header to specify a JWT and then trust that the reverse proxy in front validates the JWT and only pull the sub/email etc
• Could also put group membership as a claim into this
• More full featured, It's not complex to allow a runtime configuration of a joken via an environment feature flag. We could pull the identity from the payload and have it be the source of identity enforcement

Audit Trail

Something like:

• user accesses live route / regular route
• user evaluates a code block
  • could be as simple as the name of the notebook
  • or a hash of the code block
  • or the file disk location of the notebook at the time of run

App only execution role

Being able to have a set of people developing code books, and be able to deploy them via kino apps. Then only allow a certain group to be able to run this.

This doesn't have to be coupled to the identity portion, but could be. Having a reverse proxy in front of livebook we could allow for users that come in through the proxy to set a http header and feature flag being able to turn this feature on and off

OIDC service accounts

having aws secret key/id's can lead to being forced to rotate often. One of the nice ways around this is to push the identity chain as a part of the runtime.

This already works with :ex_aws_sts

if it's something we find interesting for the aws s3 integration I can investigate the complexity of being able to feature flag this for implicit trust.

Docker image lock downs

Having a hardened image / minimal image would be a plus for more restricted environments.

for example, at the time of writing this:

Tested 175 dependencies for known issues, found 122 issues.

Base Image        Vulnerabilities  Severity
debian:11.0-slim  82               10 critical, 14 high, 9 medium, 49 low

Recommendations for base image upgrade:

Minor upgrades
Base Image        Vulnerabilities  Severity
debian:11.6-slim  49               0 critical, 0 high, 0 medium, 49 low

Going to something like ubi or even alpine would limit the vulnerability scope

including limiting the run user as well

summary

Let me know if any of these would be welcome discussions / contributions and I don't mind doing the work for these as they would benefit some of the work I would use them with.

[josevalim]

Hi @spunkedy, thanks for the insightful issue.

As a general guidance, we consider Livebook to be single user. The way runtimes execute mean we can’t really provide any kind of safety for multiple users in the same Livebook. So any feature within that scope wouldn’t be considered.

I assume the app deployment bits are solved with the new deployment feature and we will have more news on this soon.

Regarding docker images, the musl compiler from alpine is generally an issue. We could try ubi, so something exploring that is welcome, but remember that it is ultimately a dev environment (or at the very least a compilation environment), so we need a more fully featured OS environment.

We will probably not going the OIDC route, but we may support zero trust auth and reading headers from Google IAP and similar for identity claims (so you would need to put auth in the front). I am not sure if there is a canonical solution here (perhaps joken) but exploration in this direction is very welcome!

[spunkedy]

As a general guidance, we consider Livebook to be single user. The way runtimes execute mean we can’t really provide any kind of safety for multiple users in the same Livebook. So any feature within that scope wouldn’t be considered.

Oh, I did not realize that, I assumed because of the live code editor showing which users had cursors / editing which cells that you were going towards that. Putting the JWT decoder into the user details would have that side effect I believe.

I assume the app deployment bits are solved with the new deployment feature and we will have more news on this soon.

Sounds good, I will wait for the app deployment stuff.

Google IAP and similar for identity claims (so you would need to put auth in the front).

Google IAP and other identity claim tokens could be a nice win.

Regarding docker images, the musl compiler from alpine is generally an issue. We could try ubi, so something exploring that is welcome, but remember that it is ultimately a dev environment (or at the very least a compilation environment), so we need a more fully featured OS environment.

This could benefit Federal environments that have more restrictions, maybe after the app deployment stuff that is coming there might be something there. I think anything sooner might be in opposition to the developer first pattern here.

next steps

For the Google IAP / header jwt token, what is the best way you would like to receive work, should I create an issue with a detailed high level and then do a PR against it?

[josevalim]

Oh, I did not realize that, I assumed because of the live code editor showing which users had cursors / editing which cells that you were going towards that. Putting the JWT decoder into the user details would have that side effect I believe.

Yes, Livebook itself can be collaborative, so you can still deploy it shared within your company, but within a same Livebook instance it is safest to assume that everyone has access to everything because any runtime can connect to the Livebook server and access information. So any sort of RBAC access needs to be done outside of Livebook by routing to difference instances. So it can be done per group rather than per user.

Sounds good, I will wait for the app deployment stuff.

And in case you missed it: https://news.livebook.dev/deploy-notebooks-as-apps-quality-of-life-upgrades---launch-week-1---day-1-2OTEWI - our idea is to allow to deploy those inside your infrastructure.

This could benefit Federal environments that have more restrictions, maybe after the app deployment stuff that is coming there might be something there. I think anything sooner might be in opposition to the developer first pattern here.

The issue is that even if you have a deployment target, you need to first build the notebook on the deployed machine, and that requires all compilation tooling as well. So I think giving ubi a try can be positive if we can install all deps too (and it is not a musl compiler).

For the Google IAP / header jwt token, what is the best way you would like to receive work, should I create an issue with a detailed high level and then do a PR against it?

Yes, starting an issue with detailed high-level sounds great!

[spunkedy]

And in case you missed it: https://news.livebook.dev/deploy-notebooks-as-apps-quality-of-life-upgrades---launch-week-1---day-1-2OTEWI - our idea is to allow to deploy those inside your infrastructure.

Yes, I am having people I work with build out kino apps in their dev enviroments that allow for an easy promotion plan. That's what originally gave me the idea for roles etc.

I actually spent time trying to lock down routes from the /app vs the root, but because of liveview, it patches the client browser as if they directly routed.

That's why I was thinking just a 'app_onlyandnormal` role might be easily derived from the JWT header.

The issue is that even if you have a deployment target, you need to first build the notebook on the deployed machine, and that requires all compilation tooling as well. So I think giving ubi a try can be positive if we can install all deps too (and it is not a musl compiler).

Ah, thank you for clarifying, I thought you wanted to be able to do things like

System.cmd("bash", ["-c", "apt-get update"]) 

I will do some investigations on what it might take and put some of the ideas .

Yes, starting an issue with detailed high-level sounds great!

Wonderful, will get this going

[spunkedy]

🤔

would another phoenix endpoint that only exposed /apps be favorable?

That would allow for upstream proxies to be able biforcrate without needing rbac in the app.

[josevalim]

Updates: we have initial support for identity providers here: https://github.com/livebook-dev/livebook/tree/main/lib/livebook/zta

Cloudflare currently supported with Google IAP currently as a WIP. See the README on how to setup it. Pull requests for other providers (such as AWS Identity) are welcome.