Skip to content
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

On Kubernetes environments with strict securityContext policies, the builder and demomode pods cannot start #1446

Open
arheom opened this issue Oct 25, 2024 · 4 comments
Labels
bug Something isn't working

Comments

@arheom
Copy link
Contributor

arheom commented Oct 25, 2024

Describe the bug

On Kubernetes environments with strict securityContext policies, the builder and demomode pods cannot start. Currently, the builder is taking the specs from the builder yaml from configuration, but it does not take also the container specs, where some securityContext policies are defined. Also the demomode pod takes the specs from the deployment.jkube.yaml, but only partially, leaving out the securityContext.

More information inside the discussion item: #1364

Steps to reproduce the behavior

  1. Add securityContext elements to the builder and demomode pods
  2. Run them, and check the yaml of the k8s files
  3. The securityContext is not taken from the configuration

Variant

Web Application

Container Management (if applicable)

Kubernetes

Operating System (if applicable)

None

Version

4.8.0

Relevant log output

No response

@arheom arheom added the bug Something isn't working label Oct 25, 2024
@arheom
Copy link
Contributor Author

arheom commented Oct 25, 2024

I will assign it to me and extend the code to take also the securityContext specs into consideration.

@mgubaidullin
Copy link
Contributor

How are you planning to achieve that?

@arheom
Copy link
Contributor Author

arheom commented Oct 28, 2024

I see 2 options to do it:

  1. To extend the current code to also take the securityContext specs specifically (like currently done with the env specs).
  2. Or to initialize the pod specs with the full builder / deployment specs and overwrite only what is minimum needed when creating the pods. So, here we dont take specifically the securityContext, but if it is defined, it will be taken automatically. I tend more to this solution, as it allows future extensibility on the specs, outside of the securityContext.
    What do you think? Or do you see a third option?

@mgubaidullin
Copy link
Contributor

The first option would be secure to implement, because much of the logic in creating the build container code is conditional. Implementing a full builder specification might require a lot of users to upgrade.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants