-
Notifications
You must be signed in to change notification settings - Fork 159
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
custom/third-party promotion steps #2996
Comments
Could you lay out the security implications at a high level? Does the configuration of the promotion process originate from untrusted sources? |
Implementing something like Envoys ext_authz filter where you have a HTTP or gRPC contract to fulfil would be ideal for me for a break glass option. Ideally provide a reference implementation in a couple languages for a simple server that can implement the contract. Similar to how Crossplane implements composition functions too. Definitely pros and cons doing this vs other ways of jamming executables/etc into a container. In theory these functions shouldn't be too latency sensitive so you shouldn't need the complexity of a sidecar type deployment, just a regular old webhook to wherever you're hosting the function call processor (AWS Lambda Function URL, pod/deployment in a k8s cluster, plain old binary hosted on a VM etc). Would need to consider how to secure the call so that the server can trust the originating client but that's a well trodden path and there's loads of prior art and options. |
@danielloader Argo CD also does something similar to that for CMPs. This will not work in Kargo's case. User defined promotion processes depend on a workspace in the file system where all of the repo cloning, file manipulation, etc. performed by your promotion steps is carried out. A simple API call to a third party would lack access to that workspace and would therefore be virtually useless. We need each Promotion's workspace to be accessible to all built-in and third-party steps of a promotion process and that constrains the design choices quite a bit. @hiddeco and @jessesuen and I have been whiteboarding options that satisfy this constraint for a while. We'll be getting more serious about weighing those and selecting one in 1Q25. |
This has been on the roadmap for quite some time, but there hadn't been an issue for it.
Maintainers have been discussing this internally for quite some time.
Due to the extensive security implications of this, there is a fair amount of prerequisite work to be completed. In particular, we need a viable strategy for isolating the execution of third-party functionality to a safe/limited context. This likely involves isolating promotion processes or even individual steps to their own containers or even their own pods, although other options are being weighed as well.
The text was updated successfully, but these errors were encountered: