Coder Social home page Coder Social logo

Comments (3)

denniseffing avatar denniseffing commented on August 16, 2024

There are three possible solutions:

  1. As a cluster operator, use Istio CNI instead of Istio init containers (Istio CNI documentation)
  2. Use Istio version 1.1.3 or higher (1.1.3 includes a fix for this)
  3. Change the Keycloak Helm chart so that securityContext is only defined on the main container instead of defining it on the top level spec. Defining it on the top level spec results in injected containers of Istio inherting the security context configuration, thus causing this issue.

from helm-charts.

xeor avatar xeor commented on August 16, 2024
  1. As a cluster operator, use Istio CNI instead of Istio init containers (Istio CNI documentation)

Thanks for the tip.. This worked like a charm, and the "problem" gone "global". This is the solution

  1. Use Istio version 1.1.3 or higher (1.1.3 includes a fix for this)

I was using 1.1.4, in the version that failed. I upgraded to 1.1.6 and enabled cni at the same time, so I'm not sure if 1.1.6 contains a fix or not..

  1. Change the Keycloak Helm chart so that securityContext is only defined on the main container instead of defining it on the top level spec. Defining it on the top level spec results in injected containers of Istio inherting the security context configuration, thus causing this issue.

A best practice might be to set it on the container-level, but then fsGroup coulnt be used. Looks like keycloak starts fine without, but not sure if there are any other bugs related.

from helm-charts.

denniseffing avatar denniseffing commented on August 16, 2024

I was using 1.1.4, in the version that failed. I upgraded to 1.1.6 and enabled cni at the same time, so I'm not sure if 1.1.6 contains a fix or not..

I tested the Keycloak chart using 1.1.6 and didn't encouter any issues regarding the init containers. I didn't test 1.1.3 myself but atleast the changelog says that it fixed the issue by explicitly setting the securityContext.runAsUser to 0 (i.e. root) for istio-init.

A best practice might be to set it on the container-level, but then fsGroup coulnt be used. Looks like keycloak starts fine without, but not sure if there are any other bugs related.

fsGroup could still be used on PodSpecification, it does not interfere with istio-init. I'll work on a PR to support Istio 1.0.x.

from helm-charts.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.