versatile-data-kit
versatile-data-kit copied to clipboard
vmware
control-service: Secure job builder image
This change instantiates a new job builder image, which will feature a set of security improvements. The first improvement is the removal of execute privileges from files composing a Data job.
Testing done: TBD
Signed-off-by: Gabriel Georgiev [email protected]
Is there a difference here between this and https://github.com/vmware/versatile-data-kit/blob/main/projects/control-service/projects/job-builder/
If yes, what is it?
If not, then please reuse it. Let's follow DRY principle (hint: use other image as base image)
Is there a difference here between this and https://github.com/vmware/versatile-data-kit/blob/main/projects/control-service/projects/job-builder/
If yes, what is it?
If not, then please reuse it. Let's follow DRY principle (hint: use other image as base image)
I prefer to keep them separate since we will completely rewrite the secure job builder image in the upcoming GitHub Issues.
Is there a difference here between this and https://github.com/vmware/versatile-data-kit/blob/main/projects/control-service/projects/job-builder/ If yes, what is it? If not, then please reuse it. Let's follow DRY principle (hint: use other image as base image)
I prefer to keep them separate since we will completely rewrite the secure job builder image in the upcoming GitHub Issues.
We need 2 types of job-builder images - one that is less restrictive secure and easier to get started with. Let's call it "default". And one that is secure. Things like support for ECR, configuration git and authentication,etc clearly belong in both so they should be provided out of the default.
Also the secure image would be an example for "DevOps" plugin - e.g how one can extend capabilities of VDK during deployment cycle.
I am not OK in replicating code both unless there's a good reason. Though I am fine if during development we diverge them but we need to go to a DRY approach by the end of the initiative.