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

Kubescan show wrong risks in mulit-container Pods #22

Open
ayoubeddafali opened this issue May 29, 2020 · 3 comments
Open

Kubescan show wrong risks in mulit-container Pods #22

ayoubeddafali opened this issue May 29, 2020 · 3 comments

Comments

@ayoubeddafali
Copy link

Hi,
We have a set of microservices deployed, and in each microservice pod we inject a linkerd proxy container alongside the application container for service mesh reasons.

Somehow, for all pods that has the injected linkerd container, kubescan shows wrong risks results.
When uninjecting manually the linkerd container from the pod, kubescan then show the correct risks.

@ayoubeddafali ayoubeddafali changed the title Kubescan show wrong risks Kubescan show wrong risks in mulit-container Pods May 29, 2020
@thehh1974
Copy link
Contributor

@ayoubeddafali - can you expand on what you mean by "wrong risk results"? The risk score should include any risk introduced by the sidecar.

@snahelou
Copy link

Hello

kubescan report also initContainers... It should not imho.

Because my deployment has :

        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop:
            - all
          runAsNonRoot: true
          runAsUser: 2020

And kube-scan report me

  • Workload allows privilege escalation
  • Workload has a container(s) with NET_RAW capability

@ayoubeddafali
Copy link
Author

@thehh1974 Thanks for responding.
It is totally the inverse, with the sidecar container present, the total risks are less than when it is not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants