search

kubernetes-client / javascript

Javascript client
Apache License 2.0
2k stars 509 forks source link

Overrides tough-cookie library #1563

Open surajprsd opened 6 months ago

surajprsd commented 6 months ago

Describe the bug Using version 0.19.0 and its has issues with request and tough-cookie library vulnerability.

This I have resolved with the overrides option in package.json in my node app as shown below to resolve the tough cookie issue.Please note that we cannot use the new rc4 version as our kubernetes api version is 1.26

"overrides": { "tough-cookie": "4.1.3" },

Want to understand if overriding tough-cookie to 4.1.3 in kubernetes/client v 0.19.0 has any known issue or possible issues with the same. Thanks

mstruebing commented 6 months ago

As tough-cookie is a request dependency and not a direct dependency of kubernetes-client/javascript we have no real control over it.

We can not say for sure, 0.19.0 requires tough-cookie@2.5.0 which is two major versions difference. At a first look it doesn't seem like the 4.0.0 breaking changes have any affect on the request library, but I did not had a very deep look at the code. https://github.com/salesforce/tough-cookie/releases/tag/v4.0.0

I couldn't find the changelog for version 3.0.0 quickly.

You should try if it works and let us know.

surajprsd commented 6 months ago

oh ok, will test and confirm here. Thanks. @mstruebing Would there be a future version upgrade for kubernetes/client-node replacing request that supports the same Kubernetes API version (which is currently supported by 0.19.0 ) or Is there an alternative for Kubernetes/client-node? Assuming kubernetes/client-node and kubernetes-client are the same

brendandburns commented 6 months ago

kubernetes/client-node is different than kubernetes-client, kubernetes/client-node is the official one, kubernetes-client was developed independently by Godaddy and others.

The request version of this client is basically deprecated, we're keeping it around until we're certain that we won't break people.

In the meantime, if you want a non-request based client, you can use this pre-release: https://www.npmjs.com/package/@kubernetes/client-node/v/1.0.0-rc4

surajprsd commented 6 months ago

@brendandburns Thanks, the latest RC4 doesn't support Kubernetes API v1.26 (using open shift) , hence stuck at this point. Tough-cookie is the main concern here as it's a critical vulnerability. Hence was trying to understand if overriding tough-cookie is the only option for now

mstruebing commented 6 months ago

With a bit of work involved you could regenerate the API specific code. That means you would be able to use older versions of this client with a newer kubernetes version or newer versions of the client with an older kubernetes version. There might be issues with our code which we do not generate but I personally never experienced this. We generate the client ourselves in our company as well.

A downside though is that you need to version/build the code yourself all the time.

I can try to get some steps outlined for how to do this maybe tomorrow.

brendandburns commented 6 months ago

RC4 should support 1.26, it was generated from 1.28 afaik and there's 2 version backward compatability.

Have you tested RC4 against 1.26?

brendandburns commented 6 months ago

Also, I believe you can override the dependency yourself in your own project by editing the package-lock.json file:

https://stackoverflow.com/questions/59096862/how-do-you-bump-a-transitive-dependency-in-package-lock-json

surajprsd commented 6 months ago

@brendandburns done, testing it for issues with override. Tried with RC4 for 1.26 and the library had issues with existing code.

@mstruebing Would be great if you can share the steps to refractor the code. Thanks

brendandburns commented 6 months ago

@surajprsd the easiest thing to do is to override the dependency in your package-lock.json as described above.

I could be wrong, but I don't think we have easy to use docs to regenerate, and I'm not sure it's worth the effort to create them for this niche use-case.

mstruebing commented 6 months ago

Overriding this dependency is definitely the better way here.

If you really want to generate your own client I outline the steps here:

  1. Clone the repository
  2. Fetch the open api specification from your kubernetes cluster: curl -k $APISERVER/openapi/v2 > "$KUBERNETES_CLIENT_JAVASCRIPT_ROOT/src/gen/swagger.json.unprocessed"
  3. Skip fetching the spec from upstream echo "export OPENAPI_SKIP_FETCH_SPEC=1" >> "${KUBERNETES_CLIENT_JAVASCRIPT_ROOT}/settings"
  4. npm run generate

That generates you a client you can use with every CRD you have available in your cluster. You are responsible for generating/versioning it yourself and can not have it as an node dependency which gets fetched from npm. But you are able to modify it the way you like and use all your CRDs with this client.

jimjaeger commented 5 months ago

Are there any update to fix the dependency chain to address CVE-2023-26136? The used request library is not maintained anymore.

k8s-triage-robot commented 2 months ago

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

k8s-triage-robot commented 1 month ago

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

jimjaeger commented 1 month ago

/remove-lifecycle rotten