I have a suspicion that it has something to do with user - not much help from the error message.

@TietjeDK is correct that it is just a misleading error message. It means one of two things is happening (or maybe both): the kubectl binary is newer than the supported version range of the cluster (so: using a v1.11 binary against a v1.8 cluster, for example) or the provided JWT is incorrectly signed.

You should be very very careful with --insecure-skip-tls-verify not only because it's bad security hygiene but also because if a kubeconfig is incorrect -- as is very likely the case here -- then seeing the x509 error is a much clearer indication than trying to troubleshoot an invalid JWT.

The indicator that makes me believe it is actually the signature of the token, and not its contents, is that if it were the contents you would seen an RBAC message User "foo@example.com" cannot list deployments in $namespace namespace, meaning the apiserver did unpack the JWT and found its assertions were insufficient for the operation. But if you sign a JWT using a random key, the JWT will not unpack since it will fail public key validation and be rejected outright.

So, the tl;dr is two-fold:

1. fix the kubeconfig to actually contain the correct certificate authority (CA) for the cluster, so --insecure-skip-tls-verify isn't required
2. while fixing kubeconfig, issue a new token for the (User | ServiceAccount) that comes from the cluster it is designed to interact with

I've had this error fixed by explicitly setting the namespace as an argument, e.g.:

kubectl set image -n foonamespace deployment/ms-userservice.....

https://www.mankier.com/1/kubectl-set-image#--namespace