Kubernetes Special Agent - Helm Installation erstellt keine Secrets

Guten Tag,

wir haben drei Kubernetes Cluster und nutzen den Kubernetes Special Agent mit Installation nach folgender Anleitung: Kubernetes überwachen

In zwei der drei Cluster funktioniert die Installation des Helm-Charts super und die Anbindung funktioniert in CheckMK. Das eine Cluster hat aber das Problem, dass ich folgende Meldung im CheckMK erhalte:

[special_kube] Agent exited with code 1: 401, Reason: Unauthorized, Message: UnauthorizedCRIT, Got no information from hostCRIT, execution time 1.0 sec

Ein ähnliches Thema habe ich bereits gefunden, das Problem scheint aber nicht ganz das Gleiche zu sein, eine Lösung konnte ich so jedenfalls nicht herbeiführen: Kubernetes 401 unauthorized

Ich habe herausgefunden, dass der ServiceAccount der durch das Helm-Chart installiert wird, keine Secrets erstellt. Jedenfalls bekomme ich beim ausgeben des Zertifikats keinen Inhalt mehr zurück:

~$ helm ls
NAME                            NAMESPACE               REVISION        UPDATED                                 STATUS          CHART           APP VERSION
checkmk-clustercollector        checkmk-monitoring      1               2022-11-08 14:37:28.686005087 +0100 CET deployed        checkmk-1.1.0   1.1.0
~$ kubectl get serviceaccounts
NAME                                                        SECRETS   AGE
checkmk-clustercollector-checkmk                            0         20m
checkmk-clustercollector-cluster-collector                  0         20m
checkmk-clustercollector-node-collector-container-metrics   0         20m
checkmk-clustercollector-node-collector-machine-sections    0         20m
default                                                     0         4h20m
~$ export CA_CRT="$(kubectl get secret $(kubectl get serviceaccount checkmk-clustercollector-checkmk -o=jsonpath='{.secrets[].name}' -n checkmk-monitoring) -n checkmk-monitoring -o=jsonpath='{.data.ca\.crt}' | base64 --decode)";
~$ echo "$CA_CRT"

~$

Folgende Versionen setze ich ein (die Kubernetes Cluster sind alle gleich installiert, OS wie Kubernetes Versionen)

  • Ubuntu 20.04 LTS
  • Kubernetes 1.24.6
  • Helm v3.10.1
  • Helm Chart checkmk-1.1.0 und App Version 1.1.0

Information zur Values-Datei:
Die Values-Datei habe ich komplett aus dem Chart übernommen und nur die Ingress-Ressource angepasst.

Hat jemand eine Idee warum hier keine Secrets für die Service-Accounts erstellt werden und somit die Anbindung nicht funktioniert? Mehrmaliges entfernen inklusive Namespace hat leider keine Besserung gebracht.

Gruß Atomique

Es werden Wetten angenommen bis Martin sich meldet :wink:

Was hat das zu bedeuten Habe ich etwas in der Dokumentation übersehen und es gibt Ärger? :sweat_smile:

Nope
alles gut. :wink:
Ist ein halber Insider.

Hallo @atomique,

seit Kubernetes 1.24 wird mit der Erzeugung eines Service-Accounts nicht mehr automatisch ein Secret erzeugt. Der/die/das Helm-Chart sollte, wenn es Kubernetes >= 1.24 erkennt, einen Befehl ausgeben, wie du ein Token erzeugen kannst. Das müsste ungefähr so aussehen:

kubectl create token --duration=0s -n checkmk-monitoring myrelease-checkmk-checkmk

Hast du diese Meldung gesehen und ein entsprechendes Token erzeugt?

1 Like

Hallo @sebkir,

vielen Dank für deine Antwort. Ich habe gerade mal den Cluster-Collector entfernt und erneut installiert, da ich mich nicht an eine solche Meldung erinnern konnte. Das hier ist das Ergebnis meiner Installation:

$ helm upgrade --install -n checkmk-monitoring --create-namespace checkmk-clustercollector tribe29/checkmk --version=1.1.0 -f values.yaml

Release "checkmk-clustercollector" does not exist. Installing it now.
W1110 13:35:23.435229     625 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
W1110 13:35:23.507812     625 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
W1110 13:35:23.585674     625 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
W1110 13:35:25.338720     625 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
W1110 13:35:25.344595     625 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
W1110 13:35:25.344622     625 warnings.go:70] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
W1110 13:35:25.659525     625 warnings.go:70] spec.template.metadata.annotations[seccomp.security.alpha.kubernetes.io/pod]: deprecated since v1.19, non-functional in v1.25+; use the "seccompProfile" field instead
W1110 13:35:25.681740     625 warnings.go:70] spec.template.metadata.annotations[seccomp.security.alpha.kubernetes.io/pod]: deprecated since v1.19, non-functional in v1.25+; use the "seccompProfile" field instead
W1110 13:35:25.764480     625 warnings.go:70] spec.template.metadata.annotations[seccomp.security.alpha.kubernetes.io/pod]: deprecated since v1.19, non-functional in v1.25+; use the "seccompProfile" field instead
NAME: checkmk-clustercollector
LAST DEPLOYED: Thu Nov 10 13:35:23 2022
NAMESPACE: checkmk-monitoring
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
You can access the checkmk `cluster-collector` via:
Ingress:
  http://clustercollector.domain.tld/
  # Cluster-internal DNS of `cluster-collector`: checkmk-clustercollector-cluster-collector.checkmk-monitoring
With the token of the service account named `checkmk-clustercollector-checkmk` in the namespace `checkmk-monitoring` you can now issue queries against the `cluster-collector`.
Run the following to create a token and fetch the ca-certificate of the cluster:
  export TOKEN=$(kubectl create token --duration=0s -n checkmk-monitoring checkmk-clustercollector-checkmk);
  export CA_CRT="$(kubectl get configmap kube-root-ca.crt -o 'jsonpath={.data.ca\.crt}')";
To test access you can run:
  curl -H "Authorization: Bearer $TOKEN" clustercollector.domain.tld//metadata | jq

Hier ist kein Hinweis dazu gegeben. Ich werde das erstellen des Secrets eben ausprobieren und dir Feedback geben!

Einziger Unterschied zu den anderen Clustern ist hier, dass dieses Cluster direkt in 1.24.6 installiert wurde und CheckMK erstmals auf dieser Version. Bei den beiden anderen Clustern (in denen es funktioniert) kamen wir von 1.21.X mit bereits installiertem Cluster-Collector auf 1.24.6. Daher klingt deine Annahme schon definitiv nach dem Ursprung meines Problems bzw. das würde es bestätigen.

Danke dir.

Edit: Ich habe das Token gerade erzeugt, weiß aber nicht was ich damit nun so recht anfangen soll. Ist dies das gleiche Token, dass wir in der Anleitung zu erzeugen haben und das dann in CheckMK in Passwords hinterlegt wird?

Ja genau. Dieses Token muss in Checkmk in der Kubernetes-Regel unter “Token” angegeben werden.

1 Like

Hallo @sebkir,

danke für deine Unterstützung. Es funktioniert nun mit den Hinweisen die man aus der Helm-Installation enthält. Mein “Fehler” war hier der Dokumentation zu folgen.
Eventuell wäre es sinnvoll diese wenigstens um einen Hinweis in Bezug auf 1.24 zu versehen!

Im Prinzip (für Nachfolgende): Anleitung folgen, aber bei Cert und Token definitiv die Schritte aus der Helm-Installation nehmen.

Vielen Dank! Das Cluster wird nun ordentlich und grün angezeigt. Die Serviceaccounts sind aber weiterhin ohne Secrets hinterlegt - In der Hoffnung, dass das korrekt ist :wink:

Gruß atomique

Guten Tag!
Ich muss mich leider nochmal melden. Es taucht das gleiche Fehlerbild auf wie ich bereits zu Beginn hatte. Ich habe mich gestern in Sicherheit gewähnt, weil alles grün war. Nun schaue ich heute Morgen ins Monitoring rein und sehe, dass die Datasource des Clusters wieder auf rot gesprungen ist und die gleichen Fehlermeldungen auftauchen wie zu Beginn! :frowning:

[special_kube] Agent exited with code 1: 401, Reason: Unauthorized, Message: UnauthorizedCRIT, Got no information from hostCRIT, execution time 1.1 sec

image

Irgendeine Idee wo ich ansetzen kann? Zertifikat und Token sind in CheckMK hinterlegt. Sind diese eventuell nur kurzfristig nutzbar und ich habe einen Schritt übersprungen?

Vielen Dank!

atomique

Hallo zusammen,

Ein kurzer Hinweis bzgl. eines Problems das ich gerade damit hatte:

Das Deployment des helm charts erzaehlt einem am
dass man es mit folgendem curl Befehl testen kann:

To test access you can run:
  curl -H "Authorization: Bearer $TOKEN" clustercollector.domain.tld//metadata | jq

In dieser Ausgabe sind zwei Schraegstriche (slash-slash). Wenn man das so
eingibt, dann heisst’s:

{
  "detail": "Not Found"
}

Mit einem Schraegstrich, tut’s:

{
  "cluster_collector_metadata": {
    "node": "--- REDACTED ---",
    "host_name": "--- REDACTED ---",
    "container_platform": {
      "os_name": "alpine",
      "os_version": "3.15.4",
      "python_version": "3.10.5",
      "python_compiler": "GCC 10.3.1 20211027"
    },
    "checkmk_kube_agent": {
      "project_version": "1.1.0"
    }
  },
--- Output intentionally truncated ---

Das muesste im Chart (?) korrigiert werden.

Gruesse,
Thomas

Das gleiche Problem hatte ich auch, hatte auch überprüft ob ich das in meiner Values aus Versehen falsch gesetzt hatte. Aber dort war kein / gesetzt worden. Sieht man auch in meinem Output oben.

1 Like

Erstmal zu dir Thomas:
Das zweite // kommt dadurch, dass du ein trailing / bei in der values.yaml irgendwo angegeben hast. Damit wird Helm in der Erstellung der Notes nicht einfach so umgehen können. Muss es aber auch nicht, da der Collector auch so richtig erstellt wird.

To test access you can run:
{{- if .Values.clusterCollector.ingress.enabled }}
{{- if $.Values.tlsCommunication.enabled }}
  curl -k -H "Authorization: Bearer $TOKEN" https://{{ (first .Values.clusterCollector.ingress.hosts).host }}{{ (first ((first .Values.clusterCollector.ingress.hosts).paths)).path }}/metadata | jq
{{- else }}
  curl -H "Authorization: Bearer $TOKEN" {{ (first .Values.clusterCollector.ingress.hosts).host }}{{ (first ((first .Values.clusterCollector.ingress.hosts).paths)).path }}/metadata | jq
{{- end }}
{{- if $.Values.networkPolicy.enabled }}
...

@sebkir hat es eigtl. schon alles beantwortet.
Wenn du ein aktuelles Helm Chart von uns verwendest (Version 1.1.0: Releases · tribe29/checkmk_kube_agent · GitHub), dann kommt automatisch der entsprechende Hilfetext bei der Installation (siehe Code).
Welches du bei dir hast, findest du über helm list -A

{{- if semverCompare ">= 1.24-0" (include "checkmk.kubeVersion" .) }}
Run the following to create a token and fetch the ca-certificate of the cluster:
  export TOKEN=$(kubectl create token --duration=0s -n {{ .Release.Namespace }} {{ template "checkmk.serviceAccountName.checkmk" . }});
  export CA_CRT="$(kubectl get configmap kube-root-ca.crt -o 'jsonpath={.data.ca\.crt}')";
{{- else }}
Run the following to fetch its token and the ca-certificate of the cluster:
  export TOKEN=$(kubectl get secret $(kubectl get serviceaccount {{ template "checkmk.serviceAccountName.checkmk" . }} -o=jsonpath='{.secrets[*].name}' -n {{ .Release.Namespace }}) -n {{ .Release.Namespace }} -o=jsonpath='{.data.token}' | base64 --decode);
  export CA_CRT="$(kubectl get secret $(kubectl get serviceaccount {{ template "checkmk.serviceAccountName.checkmk" . }} -o=jsonpath='{.secrets[*].name}' -n {{ .Release.Namespace }}) -n {{ .Release.Namespace }} -o=jsonpath='{.data.ca\.crt}' | base64 --decode)";
  # Note: Quote the variable when echo'ing to preserve proper line breaks: `echo "$CA_CRT"`
{{- end }}

Zu deinem aktuellen Problem: Das Token, welches in Checkmk hinterlegt ist, wird nicht von Kubernetes akzeptiert.
Kann es sein, dass das Token sich geändert hat? Oder hat das jemand gelöscht? Sonst gehen die eigtl. nicht weg. Kannst du prüfen mit

kubectl get secret $(kubectl get serviceaccount checkmk-checkmk -o=jsonpath='{.secrets[*].name}' -n checkmk-monitoring) -n checkmk-monitoring -o=jsonpath='{.data.token}' | base64 --decode

Entsprechend anpassen. Du solltest hier ein Token bekommen. Falls das nicht da ist, dann wissen wir zumindest wo der Hund liegt

Hab es rausgefunden…
Die Tokens haben nur eine kurze Laufzeit mittlerweile. Siehe

Danke fuer Deine Antwort, Martin.

Das einzige was ich in der “values.yml” geandert hatte, war die
ingress URL. DIese endet nicht mit einem slash… Sei’s drum,
das Problem ist ja leicht zu loesen.

Gruesse,
Thomas

Hi @martin.hirschvogel

vielen Dank für deine Antwort. Ich habe versucht herauszufinden, welche Zeiträume man für diese Token setzen kann. Eine Antwort habe ich nicht gefunden, da die Dokumentation von Kubernetes hier nicht wirklich detailliert ist. Das hier sollte eigentlich der relevante Eintrag sein:

Ich habe das jetzt mal folgendermaßen erstellt:

kubectl create token --duration=8760h -n checkmk-monitoring checkmk-clustercollector-checkmk

Weißt du/jemand wie ich mir die Token für einen Serviceaccount ansehen kann? Habe das irgendwie nicht hinbekommen. Mich interessiert hier eigentlich auch nur die Lifetime. Das Token selbst wird wahrscheinlich nicht anzuzeigen sein, ist ja bei Token meistens so.

Gelöscht wurde das Token auf jeden Fall nicht von meiner Seite, ich vermute hier auch eher den automatischen Ablauf. Das würde dafür sprechen warum plötzlich alles nach gegebener Zeit von grün auf rot springt und ich einen 401 zu sehen bekomme.

Gruß atomique

Du kannst einfach --output yaml dranhängen. Dann siehst du übrigens auch, ob es so angenommen wurde.
0s = Default = 3600s = 1h :smiley:

~$ kubectl create token -n temp temp-service-account --duration=0s --output yaml
apiVersion: authentication.k8s.io/v1
kind: TokenRequest
metadata:
  creationTimestamp: null
spec:
  audiences:
  - https://kubernetes.default.svc.cluster.local
  boundObjectRef: null
  expirationSeconds: 3600
status:
  expirationTimestamp: "2022-11-14T13:14:16Z"
  token: xx

Wenn man es ändert, sieht man im output, dass es sich der Wert wie gewollt ändert

~$ kubectl create token -n temp temp-service-account --duration=4400s --output yaml
apiVersion: authentication.k8s.io/v1
kind: TokenRequest
metadata:
  creationTimestamp: null
spec:
  audiences:
  - https://kubernetes.default.svc.cluster.local
  boundObjectRef: null
  expirationSeconds: 4400
status:
  expirationTimestamp: "2022-11-14T13:27:42Z"
  token: xx