Kubernetes Special Agent - Helm Installation erstellt keine Secrets

atomique · November 8, 2022, 2:04pm

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

rprengel · November 9, 2022, 5:20am

Es werden Wetten angenommen bis Martin sich meldet

atomique · November 9, 2022, 8:07am

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

rprengel · November 9, 2022, 8:18am

Nope
alles gut.
Ist ein halber Insider.

sebkir · November 9, 2022, 3:16pm

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?

atomique · November 10, 2022, 12:41pm

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?

sebkir · November 10, 2022, 1:15pm

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

atomique · November 10, 2022, 3:26pm

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

Gruß atomique

atomique · November 11, 2022, 8:51am

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!

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

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

openmindz · November 11, 2022, 12:32pm

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

atomique · November 11, 2022, 3:23pm

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.

martin.hirschvogel · November 14, 2022, 8:52am

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 }}
...

github.com

tribe29/checkmk_kube_agent/blob/main/deploy/charts/checkmk/templates/NOTES.txt#L39


      
          {{- 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 }}
          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 }}
            NOTE: You have NetworkPolicies enabled, so you need to make sure traffic from your ingress-controller is allowed.
          {{- end }}
          {{- else if contains "NodePort" .Values.clusterCollector.service.type }}

martin.hirschvogel · November 14, 2022, 9:04am

@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

martin.hirschvogel · November 14, 2022, 9:19am

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

openmindz · November 14, 2022, 9:23am

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

atomique · November 14, 2022, 10:55am

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

martin.hirschvogel · November 14, 2022, 12:24pm

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

~$ 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

martin.hirschvogel · December 12, 2022, 2:22pm

A fix is now included in the current helm chart with the release of v1.2.0 of the K8s collectors.

system · December 12, 2023, 2:22pm

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.