rke2 v1.21.3+rke2r1 single node - "401 unauthorized" after https request on port 6443

[lucaspinacci41]

Hello everybody,

I'm running in circles in the last days because of an issue I cannot solve even if the reason seems trivial: the installation of RKE2 server on a single node ends up successfully and I try to access the dashboard but everytime I get is a "401 unauthorized" via port 6443.
I just followed the Rancher documentation for setting up a Rancher cluster on k8s but I'm stuck in the same issue.

This is the cluster ('kubectl get pods -A'):
NAMESPACE NAME
cattle-system rancher-5dfdd779dc-mwtmd
cattle-system rancher-webhook-6cccfd96b5-kzjd7
cert-manager cert-manager-6d87886d5c-cqwcl
cert-manager cert-manager-cainjector-55db655cd8-7knqd
cert-manager cert-manager-webhook-7d8c86cb4c-4h6tq
fleet-system fleet-agent-d59db746-4t772
fleet-system fleet-controller-79554fcbf5-sxps5
fleet-system gitjob-568c57cfb9-gkskh
kube-system cloud-controller-manager-ubuntu2004
kube-system etcd-ubuntu2004
kube-system helm-install-rke2-canal-bpp9c
kube-system helm-install-rke2-coredns-jblrf
kube-system helm-install-rke2-ingress-nginx-zbvsm
kube-system helm-install-rke2-metrics-server-vrnmp
kube-system kube-apiserver-ubuntu2004
kube-system kube-controller-manager-ubuntu2004
kube-system kube-proxy-ubuntu2004
kube-system kube-scheduler-ubuntu2004
kube-system rke2-canal-9nkrm
kube-system rke2-coredns-rke2-coredns-74bbf4ccc7-rx2cm
kube-system rke2-ingress-nginx-controller-pnnk8
kube-system rke2-metrics-server-6647ffc866-6k8rr
rancher-operator-system rancher-operator-595ddc6db9-q94k9

Looking at the pods' logs I cannot see any specific error making me think of the issue reason.

This is the output from the https request ('https://my_server_ip:6443'):
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {

},
"status": "Failure",
"message": "Unauthorized",
"reason": "Unauthorized",
"code": 401
}

And the following is the same above request made with curl:
root@ubuntu2004:/home/ubuntu# curl -v -k https://my_server_ip:6443

• Trying my_server_ip:6443...
• TCP_NODELAY set
• Connected to my_server_ip (my_server_ip) port 6443 (#0)
• ALPN, offering h2
• ALPN, offering http/1.1
• successfully set certificate verify locations:
• CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
• TLSv1.3 (OUT), TLS handshake, Client hello (1):
• TLSv1.3 (IN), TLS handshake, Server hello (2):
• TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
• TLSv1.3 (IN), TLS handshake, Request CERT (13):
• TLSv1.3 (IN), TLS handshake, Certificate (11):
• TLSv1.3 (IN), TLS handshake, CERT verify (15):
• TLSv1.3 (IN), TLS handshake, Finished (20):
• TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
• TLSv1.3 (OUT), TLS handshake, Certificate (11):
• TLSv1.3 (OUT), TLS handshake, Finished (20):
• SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
• ALPN, server accepted to use h2
• Server certificate:
• subject: CN=kube-apiserver
• start date: Jul 30 15:49:06 2021 GMT
• expire date: Aug 2 07:48:05 2022 GMT
• issuer: CN=rke2-server-ca@1627660146
• SSL certificate verify result: self signed certificate in certificate chain (19), continuing anyway.
• Using HTTP2, server supports multi-use
• Connection state changed (HTTP/2 confirmed)
• Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
• Using Stream ID: 1 (easy handle 0x55f1d2936e10)

GET / HTTP/2
Host: my_server_ip:6443
user-agent: curl/7.68.0
accept: /

• TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):

• Connection state changed (MAX_CONCURRENT_STREAMS == 250)!
  < HTTP/2 401
  < cache-control: no-cache, private
  < content-type: application/json
  < content-length: 165
  < date: Sat, 07 Aug 2021 16:21:21 GMT
  <
  {
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {

  },
  "status": "Failure",
  "message": "Unauthorized",
  "reason": "Unauthorized",
  "code": 401

• Connection #0 to host my_server_ip left intact

Any clue?

Thank you!

BR,
Luca.

[vincent99]

6443 is the Kubernetes API, and the API correctly requires authorization.

Rancher is exposed via an ingress rule through the ingress controller, which is listening on the normal https port of 443 (unless you've changed it (and changing it to 6443 would be bad).

[lucaspinacci41]

Hi Vincent,
yes that is true but accessing Rancher via port 443 returns a "404 not found"... Any clue?
Thx!

[vincent99]

The ingress rule is for the hostname you configured at install and the request from your browser/curl has to match it. You can't access it by IP.

[lucaspinacci41]

You are right, my curl request was wrong because of the IP address but while I try to access Rancher via web (https://rancher.example.com:443) I always get a "404 not found" and I'm sure that is the proper host name used during installation. Il dom 8 ago 2021, 12:04 Vincent Fiduccia ***@***.***> ha scritto:

…

The ingress rule is for the hostname you configured at install and the request from your browser/curl has to match it. You can't access it by IP. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1569 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIXJGPYZUERFGXJYL4XVCG3T3ZJDLANCNFSM5BXRWYBA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[g1i7ch]

I have the same problem, can someone point me in the right direction as to how to set the proper host name?

[stale]

This repository uses a bot to automatically label issues which have not had any activity (commit/comment/label) for 180 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the bot can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the bot will automatically close the issue in 14 days. Thank you for your contributions.