How will security work?

[RussellWaite]

There are a few things we'd need to consider, especially if local build servers are supported, including:

Secrets, how do we store and retrieve them?

Job initiation, how do we ensure it's a valid request and not some hacker sending curl requests to DOS the build servers?

Should we allow a local build server to run a deploy to production container/step?

How does user authentication/authorisation work?

[Klaven]

IMO. the ability to deploy or run things to environments should be dictated by rbac? aka, if the server has keys to run a pipeline to deploy to prod, the use of those should be protected by rbac, when the local run goes to run, it would have to obtain those from the server. If the server can't be reached, or rbac fails the local environment should be checked for those variables... we could also provide a --config option that would be used first.

[RussellWaite]

I guess I am just paranoid about the credentials to connect to production being sent to a developer's machine and used in a container which isn't really secure, intercepting network traffic or debugging the process could lead to credential leak. Maybe we suggest to avoid it but allow it and it's up to people to pick their own level of acceptable risks.

However if we go down that path then we need to be able to run a job across multiple build servers - i.e. build and test on local but deploy on server-side build server. Which means we need to have the volume that is being mapped (assuming we go with that) as portable over many build servers. So we'd need a format like tar or OCI. Maybe just a step (container) that converts the volume to a portable format would be good enough?