Open cmoulliard opened 8 years ago
cmoulliard
commented
8 years ago This piece of code (part of the Bearer Token Filter) is working locally
Output
https://gist.github.com/cmoulliard/f277724b4371862d018dff84035c0cba
Code
https://gist.github.com/cmoulliard/8187710903ba975c9477c9438e06a5cc
I will check with @KurtStam, Marc Savy
pires
commented
8 years ago I seem to be having the same issue here with the Elasticsearch discovery plug-in. /cc jimmidyson
jimmidyson
commented
8 years ago Are you sure the service account token mounted in the pod is valid?
ashmere
commented
8 years ago @jimmidyson @pires yes I'm also seeing this with the elasticsearch discovery plugin, I've docker exec into the pod and confirmed the service account is mounted
docker exec -it 585006a26a61 /bin/bash
bash-4.3# ls -la /var/run/secrets/kubernetes.io/serviceaccount/
total 8
drwxrwxrwt 3 root root 140 Oct 17 13:39 .
drwxr-xr-x 3 root root 4096 Oct 17 13:39 ..
drwxr-xr-x 2 root root 100 Oct 17 13:39 ..109810_17_10_13_39_50.409513327
lrwxrwxrwx 1 root root 33 Oct 17 13:39 ..data -> ..109810_17_10_13_39_50.409513327
lrwxrwxrwx 1 root root 13 Oct 17 13:39 ca.crt -> ..data/ca.crt
lrwxrwxrwx 1 root root 16 Oct 17 13:39 namespace -> ..data/namespace
lrwxrwxrwx 1 root root 12 Oct 17 13:39 token -> ..data/tokenI'm seeing this with kubernetes 1.4.0
jimmidyson
commented
8 years ago Mounted doesn't necessarily mean valid... especially if you're using RBAC.
In the pod, can you try running curl -vvv -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" https://kubernetes.default.svc/api/v1/namespaces/default/endpoints/<SERVICE_NAME>? You should some output which may include the error hopefully.
madchap
commented
7 years ago Hi there,
Starting off really with k8s, launching some elasticsearch deployment.. but I am getting the same error (yet, not all the time?). I am running on a multinode setup of coreos-kubernetes with fabric8 elasticsearch discovery plugin at https://github.com/fabric8io/elasticsearch-cloud-kubernetes.
Running the command as specified in the last post from the pod itself seems satisfatory:
< $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" https://kubernetes.default.svc/api/v1/namespaces/es/endpoints/es -k
* Hostname was NOT found in DNS cache
* Trying 10.3.0.1...
* Connected to kubernetes.default.svc (10.3.0.1) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Request CERT (13):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* Server certificate:
* subject: CN=kube-apiserver-172.17.4.101
* start date: 2017-03-11 09:39:04 GMT
* expire date: 2018-03-11 09:39:04 GMT
* issuer: CN=kube-ca
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
> GET /api/v1/namespaces/es/endpoints/es HTTP/1.1
> User-Agent: curl/7.38.0
> Host: kubernetes.default.svc
> Accept: */*
> Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJlcyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJlbGFzdGljc2VhcmNoLXRva2VuLWRiOGhxIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6ImVsYXN0aWNzZWFyY2giLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiJkZjlmNTFmNi0wNzY5LTExZTctOThlNy0wODAwMjdkYmZhNGEiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6ZXM6ZWxhc3RpY3NlYXJjaCJ9.BdjVC7CFELAdF93WMbHmLaaZmNr-C0CtNyPuwHbs6GKKIzVOs--v_9c6M2lqMSsYa1WtzuQ3T5piRZM0Oo0ZPsL7Ljb2N6_XJbl6TkqD2Lgj6HHCEX1hnsl_Xc964EURIDWUrBj1WvTZkIDniYQdl3cFQjbfhjG7AwvSSnFuNd8Nl53MdX5Iu8nnpOJodf40ktWlF804ZxSz9HspQqQIOv5aCb9bVrszvt5bypou2zVM3LfAOA1lyA9YIk6U8rq4tp6k9w2ErbjMk0OE8LTlKO1Iik_M-MDlJOHOYxHrq8g9UQQ0JG2Y9tvFUDGWcjBi47eJIoJLMjM4V6hzUnH7NQ
>
< HTTP/1.1 200 OK
< Content-Type: application/json
< Date: Sun, 12 Mar 2017 21:25:16 GMT
< Content-Length: 402
<
{
"kind": "Endpoints",
"apiVersion": "v1",
"metadata": {
"name": "es",
"namespace": "es",
"selfLink": "/api/v1/namespaces/es/endpoints/es",
"uid": "dfac7573-0769-11e7-98e7-080027dbfa4a",
"resourceVersion": "223570",
"creationTimestamp": "2017-03-12T21:21:36Z",
"labels": {
"app": "es",
"env": "sandbox",
"tier": "backend"
}
},
"subsets": []
* Connection #0 to host kubernetes.default.svc left intactVersions:
Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.3", GitCommit:"029c3a408176b55c30846f0faedf56aae5992e9b", GitTreeState:"clean", BuildDate:"2017-02-15T06:40:50Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.3+coreos.0", GitCommit:"8fc95b64d0fe1608d0f6c788eaad2c004f31e7b7", GitTreeState:"clean", BuildDate:"2017-02-15T19:52:15Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}OK, I really have to have random outcomes here... was working peachy last night, re-fired up my vagrant coreos-kubernetes, and here it is back again :-'(
Running the curl this time shows me unauthorized, this time around. Oddly enough, out of my 8 ES nodes, a few do have access, whereas they share the same yaml...
madchap
commented
7 years ago Worse than that. If I call the curl command over and over again, on the same running container, I am authorized one time, and the next not, etc...
lannyMa
commented
7 years ago +1
Apiman reports this error within its log when we open the Apiman GUI Manager
fabric8 is the ServiceAccount defined within the pom.xml file of Apiman
Namespace used : default