Bots, linked projects, private secrets #3995
Replies: 4 comments 3 replies
-
|
If I recall, we also have discussed per integration custom operations that can read from Parameter Store. That does introduce vendor specific code into server, but is logically isolated and perhaps plugin-izable. |
Beta Was this translation helpful? Give feedback.
-
1. Private secrets in linked projects
This all makes sense to me. It will be important to have a philosophy on which creds live in the Home project vs. Linked Project. On Medplum Hosted, that's easy - all the creds owned by Medplum Inc. live in the home project, which we manage. For self-hosted - all the creds that are specific to that integration ? I'll throw one curve ball introduced by a user. There are cases when a first-party integration Bot might need to be linked into a project multiple times, with different secrets. The concrete example here is a large customer that actually has multiple Health Gorilla accounts that they acquired through M&A. They want multiple instances of the HG integration Bot(s), each pointing to a different HG account.
This is a really good question. A possible strategy could be to allow a Bot to have multiple ProjectMemberships into the "linked" project, and have some per-instance credentials sit on the This is off-the-cuff and definitely has a smell to it. We did get in trouble in the past for allowing multiple PMs into the same project for Users, so I want to be careful. |
Beta Was this translation helpful? Give feedback.
-
Yeah, my first instinct was ProjectMembership.secrets, which could have the exact same shape as Project.secrets. I understand the need. I consider that orthogonal to this specific discussion (the issue exists independently of project linking). I'm ok to punt on this in the short term. |
Beta Was this translation helpful? Give feedback.
-
2. General purpose key/value store APIThis makes sense as a generalization of the vendor-specific server logic we wanted. How do you imagine key namespacing working behind the scenes? By the "linked" project id? |
Beta Was this translation helpful? Give feedback.
-
|
If we can get away with per-user values, then the key could be If we need to go per-project values, then the key would probably be I'd emphasize that this is not intended to be a sharing mechanism. The main point is to expose a caching primitive for cases where the auth step is slow/heavy/expensive. |
Beta Was this translation helpful? Give feedback.
-
3. Custom bot lambda layersAgree that this is non-urgent and a big lift, but users would love this if it existed. We'll definitely need reasonable constraints around the layer size though. Immediate use case for things like fonts for PDF generation |
Beta Was this translation helpful? Give feedback.
-
|
Yeah... This has a lot of potential. It could be as simple as:
Good call on size limits... That led me to researching lambda limits: https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html Max 5 layers, hm, maybe that won't work. You could still do it, but you'd probably have to reimplement layer-equivalent functionality outside of the official layer model. |
Beta Was this translation helpful? Give feedback.
-
Context
We have multiple 3rd party integration projects underway at the moment. The main two are Health Gorilla for labs and Dosespot for meds.
One of the challenges for these integrations is "where do the secrets live?"
We have an open issue for custom server code to generate Health Gorilla access tokens: #3857
The idea behind that ticket is to move some of the root secrets into server config settings. That would be a valid way to move forward.
But that ticket fundamentally feels wrong to me. One of the major design goals of the entire Medplum architecture was to keep customer-specific and vendor-specific code out of the
serverproject. That design goal is the primary driver behind the entire Bot feature. Writing custom code for an integration vendor feels like conceding defeat.Alternate proposal
I think there are 3 foundational features necessary to do this "right":
1. Private secrets in linked projects
We recently released linked projects: #3909
The main motivation for the initial version is UMLS and Terminology Service.
US-Core will be a fast follow, and nicely takes advantage of project linking.
Vendor specific projects could be another great use case. Bots and supporting FHIR resources could live in a vendor specific project. That vendor integration can be enabled by linking the vendor project to the customer project.
That poses a few challenges, which are all solvable, but will take some work:
Bot.meta.project)AccessPolicy2. General purpose key/value store API
When generating access tokens for vendors, you typically want to generate once and then cache and reuse as long as the token is valid. That isn't possible today with the Bot execution model.
To work around that, I'd like to propose a super simple key/value API. It would expose
get,set, anddelete. The key/values can be scoped to the individualBotor user. It would basically be a general purpose temp storage for any given user account.The API and implementation are very straightforward.
Behind the scenes, this would just be a wrapper around Redis get/set with a default expiration of 24 hours (?).
There are some risk for abuse here -- notably users abusing too much storage. We could probably find some sensible limits here. In the short term, we can gate it behind a feature flag to observe usage patterns.
For example:
GET api.medplum.com/keyvalue/v1/{key}- get the current valuePUT api.medplum.com/keyvalue/v1/{key}- set the current valueDELETE api.medplum.com/keyvalue/v1/{key}- delete the current valueExplicit non-goals:
3. Custom bot lambda layers
The goal here is for users, customers, vendors, etc to be able to create their own Lambda Layers with their own set of 3rd party dependencies.
Because Bot lambdas are run in a heavily sandboxed environment with effectively zero permissions, this should be ok from a security perspective.
This is perhaps the most technically difficult. It's also not strictly urgent. In the short term, we can opportunistically add 3rd party libraries to the default lambda layer.
The real point of this is to define a North Star architecture for where we could go, which would be scalable and maintainable.
Beta Was this translation helpful? Give feedback.
All reactions