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

insecureSkipTLSVerify is insecure #333

Open
dudicoco opened this issue Jun 14, 2021 · 5 comments
Open

insecureSkipTLSVerify is insecure #333

dudicoco opened this issue Jun 14, 2021 · 5 comments

Comments

@dudicoco
Copy link

dudicoco commented Jun 14, 2021

The insecureSkipTLSVerify: true flag is used within the deployment manifest:

insecureSkipTLSVerify: true

According to the k8s api docs this should not be used: InsecureSkipTLSVerify disables TLS certificate verification when communicating with this server. This is strongly discouraged. You should use the CABundle instead.
https://v1-18.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#apiservicespec-v1-apiregistration-k8s-io

Was insecureSkipTLSVerify: true added because the container generates its own self signed certificate, which cannot be validated by the api server? Can this be resolved somehow?

@szuecs
Copy link
Member

szuecs commented Jun 14, 2021

@dudicoco I guess you can change it, but test it in a test cluster and we would be happy if you could report back, in case you can confirm it works or not.

@dudicoco
Copy link
Author

@szuecs per the docs, we must supply the CABundle to the configuration in order for that to work, and since kube-metrics-adapter is generating its certificates within its code, i'm not sure how can we supply the CABundle.

@szuecs
Copy link
Member

szuecs commented Jun 15, 2021

Then it's a feature request, thanks for checking. If you want you can also file a pull request.

@dudicoco
Copy link
Author

@szuecs I wouldn't define it as a feature request but more as a security vulnerability.

@szuecs
Copy link
Member

szuecs commented Jun 15, 2021

@dudicoco if you like. I think the position to successful exploit this vulnerability is an already so powerful position that you have at least dozens of possibilities to exploit the cluster. You can DoS the controller-manager with the "right" hpa for example.

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

2 participants