I've tried multiple forks of github.com/brendandburns/gcp-live-k8s-visualizer/issues/6. the current fork i'm trying to get working is (as mentioned by flx in another thread: https://github.com/0ortmann/k8s-visualizer ). I can get the interface to start up; but when teh script.js goes to getJSON("/api..."....) it tried to pull the /api URI from the current port (i.e.8001) for which it gets an unauthorized response? my apiserver is running on port 8080... any ideas?
Update: the "problem" appears to be related to (a) the fact that i'm making the browser http request from a remote host (i.e. i'm not going to http://localhost) and (b) the request filtering that the kubectl proxy is doing... adding the --disable-filter to the kubectl proxy command and doing a curl <remotehostIP>:8001/api at least gets me a response Moved Permanently instead of unauthorized. however, any curl <remotehostIP>:8001/api/v1/pods or similar gets an http 500 error... also the kubectl proxy command has
W1003 15:22:23.805574 8666 proxy.go:116] Request filter disabled, your proxy is vulnerable to XSRF attacks, pleas
e be cautious
Starting to serve on [::]:8001I1003 15:22:23.961109 8666 logs.go:41] http: proxy error: unsupported protocol sche
me ""
I1003 15:22:23.961311 8666 logs.go:41] http: proxy error: unsupported protocol scheme ""
I1003 15:22:23.961451 8666 logs.go:41] http: proxy error: unsupported protocol scheme ""
I1003 15:22:23.962003 8666 logs.go:41] http: proxy error: unsupported protocol scheme ""
(unsupported protocol scheme messages repeat forever)...
Related
My interface (an MKR Wifi 1010 Arduino) runs a very simple REST API, but when testing it with Mulesoft's Advanced Rest Client, I get this error:
The requested URL can't be reached
The service might be temporarily down or it may have moved permanently to a new web address.
The response status "0" is not allowed. See HTTP spec for more details: https://tools.ietf.org/html/rfc2616#section-6.1.1
When I check it with telnet though, it looks fine:
[bf#localhost ~]$ telnet 192.168.178.185 80
Trying 192.168.178.185...
Connected to 192.168.178.185.
Escape character is '^]'.
GET /api/gps HTTP/1.1
Host: 192.168.178.185
HTTP/1.1 200 OK
Connection: close
Content-Length: 9
Content-Type: application/json
"Success"
Connection closed by foreign host.
My question now is, is the rest client broken, or am I missing something in my reply? Of course I want any REST client to be able to process my interface correctly.
This is the exact same question as http request to https request using haproxy
However, the accepted answer does not work for me and I dont understand why
haproxy.cfg:
global
daemon
maxconn 15
defaults
mode tcp
balance first
frontend google
bind *:10005
default_backend google-url
backend google-url
server xxx google.com:443 ssl verify none
when I call curl --location --request GET 'http://localhost:10005', I receive a response that comes from google but with a 404 status
The requested URL / was not found on this server. That’s all we know.
I tried both mode tcp and mode http, same result
If I activate the logs with
mode http
bind *:10005
default_backend google-url
option httplog
log stdout format raw local0
I have this
127.0.0.1:52588 [16/Jun/2022:08:24:49.976] google google-url/xxx 0/0/49/20/69 404 1884 - - ---- 2/2/0/0/0 0/0 "GET / HTTP/1.1"
127.0.0.1:52588 [16/Jun/2022:08:24:49.938] google google/<NOSRV> -1/-1/-1/-1/1038 400 0 - - CR-- 2/2/0/0/0 0/0 "<BADREQ>"
In case this has some impact, I'm running haproxy in kubernetes and then I "port-forward" 10005 (but this does not seem to be the issue because the logs demonstrate that haproxy is correctly receiving the request and using the correct backend...)
Your curent HAProxy configuration will accept your request:
curl --location --request GET 'http://localhost:10005'
(corresponds to the first log entry)
and proxy it to Google as:
curl --location -H 'Host: localhost' --request GET 'https://www.google.com/'
(note the Host header implied; I bet this is not what you'd expect).
Google will respond with 404 and HAProxy will log the BADREQ.
This happens because HAProxy can't infer that when client request's Host header is localhost it should re-write it to google.com (or better: www.google.com) simply because it proxies to a host with that name.
You need to configure:
backend google-url
server xxx google.com:443 ssl verify none
http-request set-header host www.google.com
I am trying a test where I enable CORS for all domains (to be restricted after I get the use-case working correctly).
As far as I can tell, I should be adding --cors-allowed-origins=["http://*"] to my kube-apiserver.manifest
When I try to do that however:
spec:
containers:
- command:
- /bin/sh
- -c
- /usr/local/bin/kube-apiserver --address=127.0.0.1 --admission-control=Initializers,NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,Priority,ResourceQuota
--allow-privileged=true --anonymous-auth=false --apiserver-count=1 --authorization-mode=AlwaysAllow
--basic-auth-file=/srv/kubernetes/basic_auth.csv --client-ca-file=/srv/kubernetes/ca.crt
--cloud-provider=aws --etcd-servers-overrides=/events#http://127.0.0.1:4002
--etcd-servers=http://127.0.0.1:4001 --insecure-port=8080 --kubelet-preferred-address-types=InternalIP,Hostname,ExternalIP
--proxy-client-cert-file=/srv/kubernetes/apiserver-aggregator.cert --proxy-client-key-file=/srv/kubernetes/apiserver-aggregator.key
--requestheader-allowed-names=aggregator --requestheader-client-ca-file=/srv/kubernetes/apiserver-aggregator-ca.cert
--requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group
--requestheader-username-headers=X-Remote-User --secure-port=443 --service-cluster-ip-range=100.64.0.0/13
--storage-backend=etcd2 --tls-cert-file=/srv/kubernetes/server.cert --tls-private-key-file=/srv/kubernetes/server.key
--token-auth-file=/srv/kubernetes/known_tokens.csv --v=2 2>&1 | /bin/tee -a
--cors-allowed-origins=["https://*"]
I get the following error when trying to use kubectl get pods:
The connection to the server 127.0.0.1 was refused - did you specify the right host or port?
What exactly am I doing wrong for the setup? How do I add CORS domains to Kubernetes?
EDIT: I am now trying this:
- kube-apiserver
--cors-allowed-origins=["https://*"]
My pods no longer crash, however I still have CORS issues in my application.
I am getting errors like this:
[Error] Origin http://localhost:8080 is not allowed by Access-Control-Allow-Origin.
[Error] XMLHttpRequest cannot load https://example.com/auth/realms/name/protocol/openid-connect/token due to access control checks.
[Error] Failed to load resource: Origin http://localhost:8080 is not allowed by Access-Control-Allow-Origin. (token, line 0)
[Error] Preflight response is not successful
[Error] XMLHttpRequest cannot load https://example.com/api/v1/users/me/profile? due to access control checks.
Looks like you are trying to access your api-server with the http protocol, try:
--cors-allowed-origins=["http://*"]
As per documentation:
--cors-allowed-origins: List of allowed origins for CORS, comma separated. An allowed origin can be a regular expression to support subdomain matching. If this list is empty CORS will not be enabled.
I have tested this settings (and also http//*) against API and it works:
--cors-allowed-origins=example.com,example2.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Content-Type, Content-Length, Accept-Encoding, X-CSRF-Token, Authorization, X-Requested-With, If-Modified-Since
Access-Control-Allow-Methods: POST, GET, OPTIONS, PUT, DELETE, PATCH
Access-Control-Allow-Origin: http://example.com
Those errors looks like problem with settings on your serverside app.
Access-Control-Allow-Origin: specifies the authorized domains to make cross-domain request (you should include the domains of your REST clients or “*” if you want the resource public and available to everyone – the latter is not an option if credentials are allowed during CORS requests)
hope this help.
In production mode, the server failed to start and keeps print the following log. I cannot access the web pages. But the code runs fine in development mode. How to resolve the problem?
2017-11-23T10:04:07+08 [INFO] from play.core.server.AkkaHttpServer [main]
Listening for HTTP on /0:0:0:0:0:0:0:0:9000
2017-11-23T10:04:08+08 [WARN] from akka.actor.ActorSystemImpl [application-akka.actor.default-dispatcher-4]
Illegal request, responding with status '400 Bad Request': Request is
missing required `Host` header: Cannot establish effective URI of request
to `/`, request has a relative URI and is missing a `Host` header;
consider setting `akka.http.server.default-host-header`
2017-11-23T10:04:08+08 [WARN] from akka.actor.ActorSystemImpl [application-akka.actor.default-dispatcher-3]
Illegal request, responding with status '400 Bad Request': Request is
missing required `Host` header: Cannot establish effective URI of request
to `/`, request has a relative URI and is missing a `Host` header;
consider setting `akka.http.server.default-host-header`
the haproxy server health check did not send the Host header to the server
haproxy httpchk should be modified as this
option httpchk GET / HTTP/1.1\r\nHost:localhost
Depending on your HAProxy version the supported syntax might vary. This appears to be working with HAProxy 2.0.x
option httpchk GET /health
http-check send hdr Host localhost
Make sure to check the documentation for you version.
We have several (100+) clients in the field with a bug in the HTTP request. The request was previously working when directly routed to our Windows Server, but now with it fails with HAProxy v1.7 in front of it.
Here is an example request:
GET /index.aspx HTTP/1.1 \nHost: host\n\n
There is an extra space after the HTTP version before the \n.
Here is a snapshot of the relevant config.
frontend http_port_80
bind :80
mode http
reqrep (.)\ HTTP/1.1\ (.*) \1\ HTTP/1.1\2
option forwardfor
option accept-invalid-http-request
stats enable
use_backend cert_update if is_updater
use_backend getConsoleHTTP if is_getconsole
default_backend schedule_server
I have tried rewriting the request to remove the extra space and set the option accept-invalid-http-request to address the issue, but we still receive the same error.
{
type: haproxy,
timestamp: 1506545591,
termination_state: PR-,
http_status:400,
http_request:,
http_version:,
remote_addr:192.168.1.1,
bytes_read:187,
upstream_addr:-,
backend_name:http_port_80,
retries:0,
bytes_uploaded:92,
upstream_response_time:-1,
upstream_connect_time:-1,
session_duration:2382,
termination_state:PR
}
Does anyone have any ideas of how to fix the malformed request prior to haproxy rejecting it?