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

Istio does not work in cluster with restricted psp as default #22469

Closed
gitlawr opened this issue Aug 28, 2019 · 5 comments
Closed

Istio does not work in cluster with restricted psp as default #22469

gitlawr opened this issue Aug 28, 2019 · 5 comments
Assignees
Labels
area/documentation area/istio area/psp internal kind/bug-qa Issues that have not yet hit a real release. Bugs introduced by a new feature or enhancement
Milestone

Comments

@gitlawr
Copy link
Contributor

gitlawr commented Aug 28, 2019

Rancher Version
master 8/28

Similar to #20229, but for validating Istio.

Steps to reproduce

  • Create a custom cluster with pod security policy enabled and the default set to restricted
  • After the cluster has been created, enable Istio.
@gitlawr gitlawr added area/psp kind/bug-qa Issues that have not yet hit a real release. Bugs introduced by a new feature or enhancement area/istio labels Aug 28, 2019
@gitlawr gitlawr added this to the v2.3 milestone Aug 28, 2019
@gitlawr
Copy link
Contributor Author

gitlawr commented Aug 30, 2019

With the default configurations, Istio proxy sidecars require NET_ADMIN capability to set iptable rules, which is not ideal from security perspective.
To address this, A proper way is to use the Istio CNI plugin that operates iptables in the CNI layer, so that the sidecars can work without additional capabilities.

Here is the workflow to do that at the moment, which requires the system project to have a unrestricted PSP.

  1. Create/Edit a RKE cluster with the following configuration:
services:
  kubelet:
    extra_binds:
      - '/lib/modules:/lib/modules'

So that the cni plugin can leverage the iptables module to set networking rules.
2. Make System project nonrestricted, or grant proper PSP so that Istio control plane can set up as expected.
3. Install the cni plugin to the cluster:

# The istio-cni chart is in istio/cni repo.
helm template install/kubernetes/helm/istio-cni --name=istio-cni --namespace=kube-system \
    --set logLevel=info \
    --set excludeNamespaces={"istio-system,kube-system"} | kubectl apply -f -
  1. Enable Istio with a custom answer istio_cni.enabled: true

After these steps, Istio injected sidecars can work with restricted PSP.

NB: The Istio CNI plugin is in alpha phase at the moment, see.

@alena1108 alena1108 mentioned this issue Aug 30, 2019
7 tasks
@deniseschannon deniseschannon modified the milestones: v2.3, v2.3 - Backlog Aug 30, 2019
@soumyalj
Copy link

Tested the above steps on a PSP enabled master setup. With the workaround, Istio is functional.Graphs are displayed correctly.

Note: With the Istio CNI plugin, only Istio-proxy sidecar is deployed. Istio-init sidecar is not deployed . (In a regular setup without PSP enabled, both istio-proxy and istio-init containers are deployed)

@strowi
Copy link

strowi commented Jan 24, 2020

The namespace that uses istio also needs at least NET_ADMIN and NET_RAW psp-permissions, not only the default.
Might be worth mentioning in the docs until a fix is possible.

@deniseschannon
Copy link

@rancher-max
Copy link
Contributor

These instructions have been validated as working exactly as is. Please note that this uses istio-cni, which is currently in Alpha status at the time of the writeup: https://istio.io/about/feature-stages/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/documentation area/istio area/psp internal kind/bug-qa Issues that have not yet hit a real release. Bugs introduced by a new feature or enhancement
Projects
None yet
Development

No branches or pull requests

9 participants