{"id":39203,"date":"2019-10-31T22:28:25","date_gmt":"2019-10-31T19:28:25","guid":{"rendered":"https:\/\/prohoster.info\/blog\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf\/"},"modified":"2019-10-31T22:28:25","modified_gmt":"2019-10-31T19:28:25","slug":"zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","title":{"rendered":"Wir schlie\u00dfen die L\u00fccken im Kubernetes-Cluster. Vortrag und Transkript von DevOpsConf","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pavel Selivanov, Solutions Architect bei Southbridge und Dozent bei Slurm, hielt einen Vortrag auf der DevOpsConf 2019. Dieser Vortrag ist Teil eines der Themen im vertieften Kurs zu Kubernetes \u201eSlurm Mega\u201c.<\/p>\n

<\/p>\n

Slurm Basis: Einf\u00fchrung in Kubernetes<\/a><\/noindex> findet in Moskau vom 18. bis 20. November statt.
\nSlurm Mega: Ein Blick unter die Haube von Kubernetes<\/a><\/noindex> \u2014 Moskau, 22. bis 24. November.
\nSlurm Online: beide Kurse zu Kubernetes<\/a><\/noindex> sind jederzeit verf\u00fcgbar.<\/p>\n

\n

\r\n \"Video\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Unter dem Cut \u2014 die Entschl\u00fcsselung des Vortrags.<\/p>\n

<\/a><\/noindex><\/p>\n

Guten Tag, Kollegen und sympathisierende! Heute werde ich \u00fcber Sicherheit sprechen.<\/p>\n

<\/p>\n

Ich sehe, dass heute viele Sicherheitsbeauftragte im Raum sind. Ich entschuldige mich im Voraus, wenn ich Begriffe aus der Sicherheitswelt verwende, die nicht ganz so sind, wie ihr sie gewohnt seid. <\/p>\n

<\/p>\n

Es ist so gekommen, dass mir vor etwa einem halben Jahr ein \u00f6ffentlicher Kubernetes-Cluster in die H\u00e4nde fiel. \u00d6ffentlich bedeutet, dass es eine beliebige Anzahl von Namespaces gibt, in diesen Namespaces sind Benutzer, die in ihrem Namespace isoliert sind. Alle diese Benutzer geh\u00f6ren verschiedenen Unternehmen. Nun, es war angedacht, diesen Cluster als CDN zu verwenden. Das hei\u00dft, man bekommt einen Cluster, gibt einen Benutzer dazu, man kommt in seinen Namespace und deployt seine Frontends. <\/p>\n

<\/p>\n

Meiner vorherigen Firma wurde versucht, eine solche Dienstleistung zu verkaufen. Und ich wurde gebeten, den Cluster daraufhin zu testen, ob eine solche L\u00f6sung geeignet ist oder nicht. <\/p>\n

<\/p>\n

Ich kam in diesen Cluster. Mir wurden eingeschr\u00e4nkte Rechte und ein eingeschr\u00e4nkter Namespace gegeben. Dort verstanden die Leute, was Sicherheit ist. Sie wussten, was Role-based Access Control (RBAC) in Kubernetes ist \u2014 und sie hatten es so eingestellt, dass ich Pods nicht separat von Deployments starten konnte. Ich kann mich nicht an die Aufgabe erinnern, die ich zu l\u00f6sen versuchte, als ich einen Pod ohne Deployment starten wollte, aber ich wollte einfach einen Pod starten. Ich beschloss, zum Gl\u00fcck zu sehen, welche Rechte ich im Cluster habe, was ich kann, was ich nicht kann, was sie da gemacht haben. Nebenbei werde ich erz\u00e4hlen, was in ihrem RBAC falsch konfiguriert ist. <\/p>\n

<\/p>\n

Es kam so, dass ich nach zwei Minuten Admin-Rechte f\u00fcr ihren Cluster erhielt, in alle benachbarten Namespaces schaute, sah, dass dort produktive Frontends von Unternehmen liefen, die den Dienst bereits gekauft und sich deployed hatten. Ich konnte mich kaum zur\u00fcckhalten, nicht zu jemandem ins Frontend zu gehen und auf die Hauptseite ein obsz\u00f6nes Wort zu platzieren. <\/p>\n

<\/p>\n

Ich werde an Beispielen zeigen, wie ich das geschafft habe und wie man sich davon sch\u00fctzen sollte. <\/p>\n

<\/p>\n

Aber zuerst m\u00f6chte ich mich vorstellen. Mein Name ist Pawel Selivanov. Ich bin Architekt bei der Firma Southbridge. Ich kenne mich mit Kubernetes, DevOps und verschiedenen modernen Technologien aus. Gemeinsam mit den Ingenieuren von Southbridge arbeite ich an diesen Themen, w\u00e4hrend ich berate. <\/p>\n

<\/p>\n

Neben unserer Hauptt\u00e4tigkeit haben wir k\u00fcrzlich ein Projekt gestartet, das wir Slerms nennen. Wir versuchen, unser Wissen \u00fcber Kubernetes in die Breite zu tragen und anderen Menschen beizubringen, wie sie ebenfalls mit K8s arbeiten k\u00f6nnen. <\/p>\n

<\/p>\n

Wor\u00fcber ich heute sprechen werde. Das Thema meines Vortrags ist offensichtlich \u2013 es geht um die Sicherheit von Kubernetes-Clustern. Ich m\u00f6chte jedoch gleich zu Beginn klarstellen, dass dieses Thema sehr umfangreich ist \u2013 und ich m\u00f6chte von vornherein festhalten, wor\u00fcber ich sicher nicht sprechen werde. Ich werde keine abgedroschenen Begriffe behandeln, die im Internet bereits zum hundertsten Mal durchgekaut wurden. Dinge wie RBAC und Zertifikate. <\/p>\n

<\/p>\n

Ich werde dar\u00fcber sprechen, was mir und meinen Kollegen in Bezug auf die Sicherheit in Kubernetes-Clustern Sorgen bereitet. Wir sehen diese Probleme sowohl bei Anbietern, die Kubernetes-Cluster bereitstellen, als auch bei den Kunden, die zu uns kommen. Und sogar bei Kunden, die von anderen beratenden Administrationsunternehmen zu uns kommen. Das Ausma\u00df der Trag\u00f6die ist in der Tat sehr gro\u00df. <\/p>\n

<\/p>\n

Ich werde heute \u00fcber drei Punkte sprechen: <\/p>\n

<\/p>\n

    \n
  1. Benutzerrechte vs. Pod-Rechte. Benutzerrechte und Pod-Rechte sind nicht dasselbe. <\/li>\n
  2. Informationssammlung \u00fcber den Cluster. Ich werde zeigen, dass man aus einem Cluster alle ben\u00f6tigten Informationen sammeln kann, ohne besondere Rechte in diesem Cluster zu haben. <\/li>\n
  3. DoS-Angriff auf den Cluster. Wenn wir keine Informationen sammeln k\u00f6nnen, k\u00f6nnen wir den Cluster dennoch in jedem Fall lahmlegen. Ich werde \u00fcber DoS-Angriffe auf die Steuerelemente des Clusters sprechen. <\/li>\n<\/ol>\n

    <\/p>\n

    Ein weiteres allgemeines Thema, auf das ich hinweisen m\u00f6chte \u2013 worauf ich all dies getestet habe und wor\u00fcber ich sicher sagen kann, dass es funktioniert.<\/p>\n

    <\/p>\n

    Als Grundlage verwenden wir die Installation eines Kubernetes-Clusters mit Hilfe von Kubespray. Falls jemand es nicht wei\u00df: Das ist im Grunde genommen eine Sammlung von Rollen f\u00fcr Ansible. Wir verwenden es st\u00e4ndig in der Arbeit. Es hat den Vorteil, dass es \u00fcberall eingespielt werden kann \u2013 sowohl auf Hardware als auch in der Cloud. Eine Installationsmethode ist grunds\u00e4tzlich f\u00fcr alles geeignet. <\/p>\n

    <\/p>\n

    In diesem Cluster werde ich Kubernetes v1.14.5 verwenden. Der gesamte Kubernetes-Cluster, den wir betrachten werden, ist in Namespaces unterteilt, jeder Namespace geh\u00f6rt zu einem bestimmten Team, und die Mitglieder dieses Teams haben Zugriff auf ihren Namespace. Sie k\u00f6nnen nicht in andere Namespaces gehen, nur in ihren eigenen. Es gibt jedoch ein Admin-Konto, das Rechte f\u00fcr den gesamten Cluster hat. <\/p>\n

    <\/p>\n

    \"Wir<\/p>\n

    <\/p>\n

    Ich habe versprochen, dass das Erste, was wir tun werden, der Erhalt von Administratorrechten f\u00fcr den Cluster sein wird. Wir ben\u00f6tigen einen speziell vorbereiteten Pod, der den Kubernetes-Cluster angreift. Alles, was wir tun m\u00fcssen, ist, ihn im Kubernetes-Cluster anzuwenden. <\/p>\n

    <\/p>\n

    kubectl apply -f pod.yaml<\/code><\/pre>\n
    <\/p>\n
    Dieser Pod wird auf einen der Master des Kubernetes-Clusters gelangen. Und der Cluster wird uns danach erfreut eine Datei zur\u00fcckgeben, die admin.conf genannt wird. In dieser Datei werden alle Admin-Zertifikate aufbewahrt, und der API-Zugang zum Cluster ist ebenfalls konfiguriert. So einfach kann man Administrationszugang erhalten, ich denke, zu 98 % der Kubernetes-Cluster. <\/p>\n
    <\/p>\n
    Ich wiederhole, dieser Pod wurde von einem Entwickler in Ihrem Cluster erstellt, der Zugriff hat, um seine Vorschl\u00e4ge in einen kleinen Namespace zu deployen, der vollst\u00e4ndig durch RBAC eingeschr\u00e4nkt ist. Er hatte keinerlei Rechte. Und dennoch kam das Zertifikat zur\u00fcck. <\/p>\n
    <\/p>\n
    Jetzt zum speziell vorbereiteten Pod. Wir starten mit einem beliebigen Image. Zum Beispiel nehmen wir debian:jessie. <\/p>\n
    <\/p>\n
    Wir haben so etwas: <\/p>\n
    <\/p>\n
    tolerations:\n-   effect: NoSchedule \n    operator: Exists \nnodeSelector: \n    node-role.kubernetes.io\/master: \"\" <\/code><\/pre>\n
    <\/p>\n
    Was ist eine Toleranz? Die Master im Kubernetes-Cluster sind normalerweise mit einer Sache markiert, die taint (\u201eToxizit\u00e4t\u201c auf Englisch) genannt wird. Das Wesen dieser \"Toxizit\u00e4t\" besagt, dass auf Master-Nodes keine Pods zugewiesen werden k\u00f6nnen. Aber niemand hindert einen Pod daran, zu deklarieren, dass er gegen diese \"Toxizit\u00e4t\" tolerant ist. Der Abschnitt Toleration sagt genau, dass, wenn auf einem Node NoSchedule steht, unser Pod gegen diese Toxizit\u00e4t tolerant ist \u2013 und es gibt keine Probleme. <\/p>\n
    <\/p>\n
    Als N\u00e4chstes sagen wir, dass unser Pod nicht nur tolerant ist, sondern auch speziell auf den Master gelangen m\u00f6chte. Denn auf den Mastern befinden sich die wertvollsten Dinge, die wir ben\u00f6tigen \u2013 alle Zertifikate. Daher geben wir nodeSelector an \u2013 und wir haben ein Standardlabel auf den Mastern, das es uns erm\u00f6glicht, aus allen Nodes des Clusters genau die Nodes auszuw\u00e4hlen, die Master sind. <\/p>\n
    <\/p>\n
    Mit diesen beiden Abschnitten wird der Pod definitiv auf dem Master ankommen. Und es wird ihm erlaubt, dort zu leben. <\/p>\n
    <\/p>\n
    Aber nur auf den Master zu gelangen, reicht nicht aus. Das bringt uns nichts. Daher haben wir als N\u00e4chstes diese beiden Dinge:<\/p>\n
    <\/p>\n
    hostNetwork: true \nhostPID: true <\/code><\/pre>\n
    <\/p>\n
    Wir geben an, dass unser Pod, den wir starten, im Kern-Namensraum, im Netzwerk-Namensraum und im PID-Namensraum leben wird. Sobald der Pod auf dem Master l\u00e4uft, kann er alle echten, aktiven Schnittstellen dieses Knotens sehen, den gesamten Verkehr abh\u00f6ren und die PID aller Prozesse sehen.<\/p>\n
    <\/p>\n
    Danach ist es einfach. Nehmen Sie etcd und lesen Sie, was Sie wollen. <\/p>\n
    <\/p>\n
    Das Interessanteste ist diese M\u00f6glichkeit von Kubernetes, die dort standardm\u00e4\u00dfig vorhanden ist. <\/p>\n
    <\/p>\n
    volumeMounts:\n- mountPath: \/host \n  name: host \nvolumes:\n- hostPath: \n    path: \/ \n    type: Verzeichnis \n  name: host <\/code><\/pre>\n
    <\/p>\n
    Und die Essenz davon ist, dass wir im Pod, den wir starten, auch ohne Rechte auf diesen Cluster sagen k\u00f6nnen, dass wir ein Volume des Typs hostPath erstellen wollen. Das bedeutet, wir nehmen den Pfad vom Host, auf dem wir gestartet werden \u2014 und verwenden ihn als Volume. Und weiter benennen wir es name: host. Dieses gesamte hostPath montieren wir in den Pod. In diesem Beispiel in das Verzeichnis \/host. <\/p>\n
    <\/p>\n
    Ich wiederhole es noch einmal. Wir haben dem Pod gesagt, er solle auf den Master kommen, das hostNetwork und hostPID erhalten \u2014 und den gesamten Root des Masters in diesen Pod einbinden. <\/p>\n
    <\/p>\n
    Sie verstehen, dass wir auf Debian Bash laufen haben und dieses Bash unter Root arbeitet. Das hei\u00dft, wir haben gerade Root auf dem Master erhalten, obwohl wir keine speziellen Berechtigungen im Kubernetes-Cluster haben.<\/p>\n
    <\/p>\n
    Die gesamte Aufgabe besteht nun darin, in den Pod in das Verzeichnis \/host \/etc\/kubernetes\/pki zu gehen, falls ich mich nicht irre, und dort alle Master-Zertifikate des Clusters anzufordern und somit Admin des Clusters zu werden. <\/p>\n
    <\/p>\n
    Wenn man so schaut, sind das einige der gef\u00e4hrlichsten Berechtigungen in Pods \u2014 unabh\u00e4ngig von den Rechten, die der Benutzer hat:
    \n\"Wir<\/p>\n
    <\/p>\n
    Wenn ich das Recht habe, einen Pod in einem bestimmten Namesraum des Clusters zu starten, hat dieser Pod diese Rechte standardm\u00e4\u00dfig. Ich kann privilegierte Pods starten, und das bedeutet so gut wie alle Rechte, praktisch Root auf dem Knoten. <\/p>\n
    <\/p>\n
    Mein Favorit \u2014 Root-Benutzer. Und Kubernetes hat diese Option 'Run As Non-Root'. Das ist ein gewisser Schutz vor Hackern. Wissen Sie, was ein 'moldawischer Virus' ist? Wenn Sie pl\u00f6tzlich Hacker sind und in meinen Kubernetes-Cluster gekommen sind, dann bitten wir, arme Administratoren: 'Bitte geben Sie in Ihren Pods, mit denen Sie meinen Cluster hacken wollen, run as non-root an. Sonst kann es passieren, dass Sie einen Prozess in Ihrem Pod als Root starten und es Ihnen sehr einfach sein wird, mich zu hacken. Sch\u00fctzen Sie sich bitte selbst.' <\/p>\n
    <\/p>\n
    Das Host-Path-Volume \u2014 meiner Meinung nach der schnellste Weg, das gew\u00fcnschte Ergebnis vom Kubernetes-Cluster zu erhalten. <\/p>\n
    <\/p>\n
    Aber was sollen wir mit all dem machen? <\/p>\n
    <\/p>\n
    Gedanken, die jedem normalen Administrator kommen sollten, der mit Kubernetes konfrontiert ist: \u201eAh, ich habe es doch gesagt, Kubernetes funktioniert nicht. Es hat L\u00f6cher. Und das ganze Ding ist Mist.\u201c Tats\u00e4chlich gibt es so etwas wie Dokumentation, und wenn man dort nachschaut, gibt es einen Abschnitt Pod Security Policy<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Das ist ein yaml-Objekt \u2013 wir k\u00f6nnen es im Kubernetes-Cluster erstellen \u2013 das Aspekte der Sicherheit genau in der Beschreibung von Pods kontrolliert. Das bedeutet, dass es die Berechtigungen zum Nutzen von hostNetwork, hostPID und bestimmten Typen von Volumes, die in Pods beim Start vorhanden sind, steuert. Mit Hilfe von Pod Security Policy kann all dies beschrieben werden. <\/p>\n
    <\/p>\n
    Das Interessanteste an der Pod Security Policy ist, dass alle Installationen von PSP im Kubernetes-Cluster nicht einfach beschrieben sind, sie sind standardm\u00e4\u00dfig deaktiviert. Die Pod Security Policy wird mithilfe eines Admission-Plugins aktiviert.<\/p>\n
    <\/p>\n
    Okay, wir werden die Pod Security Policy im Cluster bereitstellen und sagen, dass wir bestimmte Service-Pods im Namespace haben, auf den nur Administratoren zugreifen k\u00f6nnen. Nehmen wir an, in allen anderen Pods sind die Berechtigungen eingeschr\u00e4nkt. Denn wahrscheinlich ben\u00f6tigen die Entwickler keine privilegierten Pods in Ihrem Cluster. <\/p>\n
    <\/p>\n
    Und es scheint alles in Ordnung zu sein. Und unser Kubernetes-Cluster kann nicht in zwei Minuten gehackt werden. <\/p>\n
    <\/p>\n
    Es gibt ein Problem. H\u00f6chstwahrscheinlich, wenn Sie einen Kubernetes-Cluster haben, ist in Ihrem Cluster \u00dcberwachung eingerichtet. Ich wage sogar vorherzusagen, dass, wenn in Ihrem Cluster \u00dcberwachung vorhanden ist, diese Prometheus hei\u00dft. <\/p>\n
    <\/p>\n
    Das, was ich jetzt sagen werde, gilt sowohl f\u00fcr den Prometheus-Operator als auch f\u00fcr Prometheus, der als reines Produkt bereitgestellt wird. Die Frage ist, dass, wenn ich im Cluster nicht so schnell einen Administrator bekommen kann, das bedeutet, dass ich mehr suchen muss. Und ich kann mit Ihrer \u00dcberwachung suchen.<\/p>\n
    <\/p>\n
    Wahrscheinlich haben alle die gleichen Artikel auf Habr gelesen, und die \u00dcberwachung befindet sich im Namespace monitoring. Das Helm-Chart hei\u00dft bei allen ungef\u00e4hr gleich. Ich nehme an, wenn Sie helm install stable\/prometheus ausf\u00fchren, werden Sie ungef\u00e4hr die gleichen Namen erhalten. Und wahrscheinlich muss ich den DNS-Namen in Ihrem Cluster nicht erraten. Weil er standardm\u00e4\u00dfig ist. <\/p>\n
    <\/p>\n
    \"Wir<\/p>\n
    <\/p>\n
    Dann haben wir einen gewissen dev ns, in dem wir einen bestimmten Pod starten k\u00f6nnen. Und dann k\u00f6nnen wir aus diesem Pod ganz einfach Folgendes machen: <\/p>\n
    <\/p>\n
    $ curl http:\/\/prometheus-kube-state-metrics.monitoring <\/code><\/pre>\n
    <\/p>\n
    prometheus-kube-state-metrics ist einer der Prometheus-Exporter, der Metriken aus der Kubernetes-API sammelt. Es gibt eine Menge Daten dar\u00fcber, was in Ihrem Cluster l\u00e4uft, wie es l\u00e4uft und welche Probleme Sie damit haben. <\/p>\n
    <\/p>\n
    Ein einfaches Beispiel: <\/p>\n
    <\/p>\n
    kube_pod_container_info{namespace=\"kube-system\",pod=\"kube-apiserver-k8s-1\",container=\"kube-apiserver\",image= <\/p>\n
    <\/p>\n
    \"gcr.io\/google-containers\/kube-apiserver:v1.14.5\" <\/strong><\/p>\n
    <\/p>\n
    ,image_id=\"docker-pullable:\/\/gcr.io\/google-containers\/kube-apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a9638ee634989\",container_id=\"docker:\/\/7cbe7b1fea33f811fdd8f7e0e079191110268f2853397d7daf08e72c22d3cf8b\"} 1 <\/p>\n
    <\/p>\n
    Mit einer einfachen curl-Anfrage aus einem nicht privilegierten Pod k\u00f6nnen Sie solche Informationen erhalten. Wenn Sie nicht wissen, welche Version von Kubernetes Sie verwenden, wird es Ihnen dies leicht erkl\u00e4ren. <\/p>\n
    <\/p>\n
    Und das Interessanteste ist, dass Sie neben dem Zugriff auf kube-state-metrics auch direkt auf Prometheus zugreifen k\u00f6nnen. Sie k\u00f6nnen Metriken von dort sammeln. Sie k\u00f6nnen sogar Metriken daraus erstellen. Theoretisch k\u00f6nnen Sie eine Anfrage aus dem Cluster an Prometheus stellen, die es einfach ausschaltet. Und Ihre \u00dcberwachung wird vollst\u00e4ndig aufh\u00f6ren, im Cluster zu funktionieren. <\/p>\n
    <\/p>\n
    Hier stellt sich die Frage, ob irgendeine externe \u00dcberwachung Ihre \u00dcberwachung \u00fcberwacht. Gerade jetzt hatte ich die M\u00f6glichkeit, im Kubernetes-Cluster ohne Folgen f\u00fcr mich zu handeln. Sie werden nicht einmal merken, dass ich dort t\u00e4tig bin, da es keine \u00dcberwachung mehr gibt. <\/p>\n
    <\/p>\n
    Ebenso wie mit PSP scheint es, als l\u00e4ge das Problem darin, dass all diese modernen Technologien \u2013 Kubernetes, Prometheus \u2013 einfach nicht funktionieren und voller L\u00f6cher sind. In Wirklichkeit ist das nicht der Fall. <\/p>\n
    <\/p>\n
    Es gibt so etwas \u2013 Network Policy<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    Wenn Sie ein normaler Administrator sind, wissen Sie wahrscheinlich, dass eine Network Policy ein weiteres YAML ist, von denen es im Cluster bereits viele gibt. Und einige Network Policies sind definitiv nicht notwendig. Selbst wenn Sie gelesen haben, dass Network Policy eine YAML-Firewall von Kubernetes ist, die den Zugriff zwischen Namespaces und Pods einschr\u00e4nkt, haben Sie wahrscheinlich entschieden, dass eine Firewall im YAML-Format in Kubernetes nur ein weiteres abstraktes Konzept ist... Nein, das ist definitiv nicht notwendig. <\/p>\n
    <\/p>\n
    Selbst wenn Ihre Sicherheitsexperten nicht dar\u00fcber informiert wurden, dass Sie mit Ihrem Kubernetes ganz einfach eine sehr granulierte Firewall erstellen k\u00f6nnen. Wenn sie das noch nicht wissen und Sie nicht fragen: \u201eNun, geben Sie, geben Sie\u2026\u201c In jedem Fall ben\u00f6tigen Sie Network Policies, um den Zugriff auf einige Dienststellen zu sperren, die Sie aus Ihrem Cluster abrufen k\u00f6nnen, ohne jegliche Autorisierung. <\/p>\n
    <\/p>\n
    Wie im Beispiel, das ich angef\u00fchrt habe, k\u00f6nnen Sie kube state metrics aus jedem Namespace im Kubernetes-Cluster abrufen, ohne daf\u00fcr irgendwelche Rechte zu haben. Die Network Policies haben den Zugriff aus allen anderen Namespaces auf den Monitoring-Namespace gesperrt, und das war's: Kein Zugriff, keine Probleme. In allen Charts, die vorhanden sind \u2013 sowohl im Standard-Prometheus als auch in dem Prometheus, der im Operator ist \u2013 gibt es einfach in den Helm-Werten eine Option, die Network Policies f\u00fcr sie zu aktivieren. Sie m\u00fcssen es einfach aktivieren, und sie werden funktionieren. <\/p>\n
    <\/p>\n
    Es gibt hier tats\u00e4chlich ein Problem. Als normaler, b\u00e4rtiger Administrator haben Sie wahrscheinlich entschieden, dass Network Policies nicht notwendig sind. Und nachdem Sie verschiedene Artikel auf Seiten wie Habr gelesen haben, haben Sie entschieden, dass Flannel, insbesondere im Host-Gateway-Modus, das Beste ist, was Sie w\u00e4hlen k\u00f6nnen. <\/p>\n
    <\/p>\n
    Was tun? <\/p>\n
    <\/p>\n
    Sie k\u00f6nnen versuchen, die Netzwerkl\u00f6sung, die Sie in Ihrem Kubernetes-Cluster haben, neu zu deployen und sie durch etwas Funktionaleres zu ersetzen. Zum Beispiel durch dasselbe Calico. Aber ich m\u00f6chte gleich sagen, dass die Aufgabe, die Netzwerkl\u00f6sung in einem produktiven Kubernetes-Cluster zu \u00e4ndern, ziemlich anspruchsvoll ist. Ich habe es zweimal gel\u00f6st (beide Male theoretisch), aber wir haben sogar in den Slorum gezeigt, wie man das macht. F\u00fcr unsere Schulungsteilnehmer haben wir gezeigt, wie man die Netzwerkl\u00f6sung in einem Kubernetes-Cluster \u00e4ndert. Prinzipiell k\u00f6nnen Sie versuchen, dies so zu machen, dass es im Produktionscluster keine Ausfallzeiten gibt. Aber wahrscheinlich wird es Ihnen nicht gelingen. <\/p>\n
    <\/p>\n
    Und das Problem l\u00e4sst sich tats\u00e4chlich ganz einfach l\u00f6sen. Im Cluster gibt es Zertifikate, und Sie wissen, dass die Zertifikate nach einem Jahr ablaufen. Nun, und normalerweise ist die \u00fcbliche L\u00f6sung mit Zertifikaten im Cluster \u2013 warum sollten wir uns damit herumschlagen, wir heben daneben einen neuen Cluster an, im alten kann er ablaufen, und wir deployen alles neu. Das Problem ist, wenn es abl\u00e4uft, werden wir einen ganzen Tag darauf warten m\u00fcssen, aber daf\u00fcr haben wir einen neuen Cluster. <\/p>\n
    <\/p>\n
    Beim Erstellen des neuen Clusters sollten Sie auch Calico anstelle von Flannel einf\u00fcgen. <\/p>\n
    <\/p>\n
    Was tun, wenn Sie Zertifikate haben, die f\u00fcr hundert Jahre ausgestellt wurden und Sie den Cluster nicht neu bereitstellen m\u00f6chten? Es gibt so ein Ding namens Kube-RBAC-Proxy. Es handelt sich um eine sehr coole Entwicklung, die es erm\u00f6glicht, sich als Sidecar-Container in jeden Pod im Kubernetes-Cluster einzuf\u00fcgen. Und es f\u00fcgt diesem Pod tats\u00e4chlich die Autorisierung \u00fcber RBAC von Kubernetes hinzu. <\/p>\n
    <\/p>\n
    Es gibt ein Problem. Fr\u00fcher war diese L\u00f6sung Kube-RBAC-Proxy in dem Prometheus-Operator integriert. Aber das gibt es jetzt nicht mehr. Die modernen Versionen st\u00fctzen sich darauf, dass Sie eine Netzwerk-Policy haben und diese verwenden, um zu schlie\u00dfen. Daher m\u00fcssen Sie das Chart ein wenig umschreiben. Wenn Sie tats\u00e4chlich in den dieses Repository<\/a><\/noindex>, dort finden Sie Beispiele, wie man dies als Sidecars verwenden kann, und die Charts m\u00fcssen minimal umgeschrieben werden. <\/p>\n
    <\/p>\n
    Es gibt noch ein kleines Problem. Nicht nur Prometheus gibt seine Metriken einfach so weiter. Auch unsere gesamten Cluster-Komponenten im Kubernetes k\u00f6nnen ihre Metriken bereitstellen. <\/p>\n
    <\/p>\n
    Aber wie ich schon sagte, wenn Sie keinen Zugang zum Cluster haben und keine Informationen sammeln k\u00f6nnen, k\u00f6nnen Sie zumindest etwas Schaden anrichten. <\/p>\n
    <\/p>\n
    Ich werde Ihnen also schnell zwei M\u00f6glichkeiten zeigen, wie man die Gesundheit eines Kubernetes-Clusters beeintr\u00e4chtigen kann. <\/p>\n
    <\/p>\n
    Sie werden lachen, wenn ich das erz\u00e4hle, es sind zwei F\u00e4lle aus dem echten Leben. <\/p>\n
    <\/p>\n
    Erste Methode. Ressourcenersch\u00f6pfung. <\/p>\n
    <\/p>\n
    Wir starten einen weiteren speziellen Pod. Er wird so eine Sektion haben. <\/p>\n
    <\/p>\n
    resources: \n    requests: \n        cpu: 4 \n        memory: 4Gi <\/code><\/pre>\n
    <\/p>\n
    Wie Sie wissen, sind die Requests die Menge an CPU und Speicher, die auf dem Host f\u00fcr bestimmte Pods mit Requests reserviert wird. Wenn wir einen vierkernigen Host im Kubernetes-Cluster haben und ein Pod mit vier CPU-Requests darauf kommt, kann kein weiterer Pod mit Requests auf diesen Host kommen. <\/p>\n
    <\/p>\n
    Wenn ich einen solchen Pod starte und dann den Befehl ausf\u00fchre: <\/p>\n
    <\/p>\n
    $ kubectl scale special-pod --replicas=...<\/code><\/pre>\n
    <\/p>\n
    Dann kann sich niemand mehr im Kubernetes-Cluster bereitstellen. Denn auf allen Knoten sind die Requests ersch\u00f6pft. Auf diese Weise werde ich Ihren Kubernetes-Cluster anhalten. Wenn ich das abends mache, kann ich Deployments ziemlich lange stoppen. <\/p>\n
    <\/p>\n
    Wenn wir ein weiteres Mal in die Dokumentation von Kubernetes schauen, werden wir etwas sehen, das als Limit Range bezeichnet wird. Es legt die Ressourcen f\u00fcr Clusterobjekte fest. Sie k\u00f6nnen ein YAML-Objekt f\u00fcr Limit Range schreiben, es in bestimmte Namespaces anwenden \u2013 und dann k\u00f6nnen Sie in diesem Namespace angeben, dass Sie Standard-, Maximal- und Minimalressourcen f\u00fcr Pods haben.<\/p>\n
    <\/p>\n
    Mit einem solchen Mechanismus k\u00f6nnen wir die Benutzer in bestimmten produktbezogenen Namespaces der Teams daran hindern, bei ihren Pods irgendwelchen M\u00fcll anzugeben. Aber leider, selbst wenn Sie dem Benutzer sagen, dass er keine Pods mit Anfragen \u00fcber eine CPU starten darf, gibt es diesen wunderbaren Befehl scale, oder \u00fcber das Dashboard k\u00f6nnen sie skalieren.<\/p>\n
    <\/p>\n
    Und hier kommt der zweite Weg ins Spiel. Wir starten 11 111 111 111 111 Pods. Das sind elf Milliarden. Das ist nicht, weil ich mir diese Zahl ausgedacht habe, sondern weil ich es selbst gesehen habe. <\/p>\n
    <\/p>\n
    Echte Geschichte. Sp\u00e4t am Abend wollte ich gerade das B\u00fcro verlassen. Ich schaue, in der Ecke sitzt eine Gruppe von Entwicklern und macht etwas hektisch mit Laptops. Ich gehe zu den Jungs und frage: \u201eWas ist passiert?\u201c<\/p>\n
    <\/p>\n
    Etwa fr\u00fcher, gegen neun Uhr abends, wollte einer der Entwickler nach Hause gehen. Und er dachte: \u201eIch werde jetzt meine Anwendung auf eins skalieren\u201c. Er dr\u00fcckte die Eins, aber das Internet hat ein bisschen gestockt. Er dr\u00fcckte noch einmal auf die Eins, er dr\u00fcckte auf die Eins, klickte auf Enter. Er klickte auf alles, was er konnte. Dann lebte das Internet wieder auf \u2013 und alles begann, auf diese Zahl zu skalieren. <\/p>\n
    <\/p>\n
    Tats\u00e4chlich fand diese Geschichte nicht auf Kubernetes statt, damals war es Nomad. Das Ganze endete damit, dass nach einer Stunde unserer Versuche, Nomad von seinen hartn\u00e4ckigen Versuchen zu skalieren abzuhalten, Nomad antwortete, dass es nicht aufh\u00f6ren w\u00fcrde zu skalieren und sich um nichts anderes k\u00fcmmern w\u00fcrde. \u201eIch habe genug, ich gehe.\u201c Und schloss sich. <\/p>\n
    <\/p>\n
    Ich habe nat\u00fcrlich versucht, dasselbe auf Kubernetes zu machen. Elf Milliarden Pods haben Kubernetes nicht erfreut, er sagte: \u201eKann ich nicht. \u00dcberschreitet interne Limits\u201c. Aber 1 000 000 000 Pods hat es geschafft. <\/p>\n
    <\/p>\n
    Als Antwort auf eine Milliarde begann Kubernetes tats\u00e4chlich zu skalieren. Je weiter der Prozess fortschritt, desto mehr Zeit ben\u00f6tigte er f\u00fcr das Erstellen neuer Pods. Aber der Prozess lief weiter. Das einzige Problem ist, dass ich, wenn ich Pods in meinem Namespace unbegrenzt starten kann, auch ohne Requests und Limits eine so gro\u00dfe Anzahl an Pods mit bestimmten Aufgaben starten kann, dass die Knoten durch diese Aufgaben im Hinblick auf den Speicher und die CPU \u00fcberlastet werden. Wenn ich so viele Pods starte, muss die Information aus ihnen in den Speicher gelangen, sprich etcd. Und wenn zu viele Informationen dort ankommen, beginnt der Speicher sehr langsam zu reagieren \u2014 und Kubernetes hat Leistungseinbu\u00dfen. <\/p>\n
    <\/p>\n
    Und ein weiteres Problem\u2026 Wie Sie wissen, bestehen die Steuerungselemente von Kubernetes nicht aus einem einzigen zentralen Element, sondern aus mehreren Komponenten. Dort gibt es unter anderem einen Controller-Manager, einen Scheduler und so weiter. All diese Komponenten beginnen gleichzeitig, unn\u00f6tige, ineffiziente Arbeiten zu verrichten, die mit der Zeit immer mehr Zeit in Anspruch nehmen. Der Controller-Manager wird neue Pods erstellen. Der Scheduler wird versuchen, ihnen einen neuen Knoten zuzuweisen. Neue Knoten in Ihrem Cluster werden Ihnen wahrscheinlich bald ausgehen. Das Kubernetes-Cluster wird immer langsamer arbeiten.<\/p>\n
    <\/p>\n
    Aber ich habe beschlossen, noch weiter zu gehen. Wie Sie wissen, gibt es in Kubernetes eine Funktion, die als Service bezeichnet wird. In der Regel arbeitet dieser Service in Ihren Clustern wahrscheinlich mit IP Tables. <\/p>\n
    <\/p>\n
    Wenn man beispielsweise eine Milliarde Pods startet und dann mit einem Skript Kubernetes anweist, neue Services zu erstellen: <\/p>\n
    <\/p>\n
    for i in {1..1111111}; do\n    kubectl expose deployment test --port 80  \n        --overrides=\"{\"apiVersion\": \"v1\", \n           \"metadata\": {\"name\": \"nginx$i\"}}\"; \ndone <\/code><\/pre>\n
    <\/p>\n
    Auf allen Knoten des Clusters werden ungef\u00e4hr gleichzeitig immer neue IP-Tables-Regeln generiert. F\u00fcr jeden Service werden eine Milliarde IP-Tables-Regeln generiert. <\/p>\n
    <\/p>\n
    Ich habe das Ganze bei mehreren Tausend, bis zu einem Dutzend \u00fcberpr\u00fcft. Und das Problem ist, dass es schon auf dieser Schwelle ziemlich schwierig ist, eine SSH-Verbindung zu einem Knoten herzustellen. Weil Pakete, die durch so viele Ketten gehen, nicht gerade gut abschneiden. <\/p>\n
    <\/p>\n
    Und auch das alles wird mit Kubernetes gel\u00f6st. Es gibt so ein Objekt namens Resource Quota. Es legt die Anzahl der verf\u00fcgbaren Ressourcen und Objekte f\u00fcr den Namespace im Cluster fest. Wir k\u00f6nnen ein YAML-Objekt in jedem Namespace des Kubernetes-Clusters erstellen. Mit diesem Objekt k\u00f6nnen wir sagen, dass f\u00fcr diesen Namespace eine bestimmte Anzahl von Requests, Limits bereitgestellt wird, und dann k\u00f6nnen wir sagen, dass in diesem Namespace 10 Services und 10 Pods erstellt werden k\u00f6nnen. Und der Entwickler kann abends machen, was er will. Kubernetes wird ihm sagen: \u201eSie k\u00f6nnen Ihre Pods nicht bis zu dieser Anzahl skalieren, weil es die Ressourcenkontingent \u00fcberschreitet\u201c. Das war's, das Problem ist gel\u00f6st. Dokumentation hier<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    Ein problematischer Punkt taucht in diesem Zusammenhang auf. Sie sp\u00fcren, wie schwierig es wird, in Kubernetes einen Namespace zu erstellen. Um ihn zu erstellen, m\u00fcssen wir viele Dinge ber\u00fccksichtigen.<\/p>\n
    <\/p>\n
    Resource Quota + Limit Range + RBAC
    \n\u2022 Namespace erstellen
    \n\u2022 Limit Range innerhalb erstellen
    \n\u2022 Resource Quota innerhalb erstellen
    \n\u2022 Service Account f\u00fcr CI erstellen
    \n\u2022 Role Binding f\u00fcr CI und Benutzer erstellen
    \n\u2022 Optional die ben\u00f6tigten Service Pods starten <\/p>\n
    <\/p>\n
    Daher m\u00f6chte ich die Gelegenheit nutzen, um meine Entwicklungen zu teilen. Es gibt so eine Sache, die Operator SDK hei\u00dft. Dies ist eine M\u00f6glichkeit, im Kubernetes-Cluster Operatoren f\u00fcr ihn zu schreiben. Sie k\u00f6nnen Operatoren mit Ansible schreiben.<\/p>\n
    <\/p>\n
    Zuerst hatten wir es mit Ansible geschrieben, und dann habe ich gesehen, dass es das Operator SDK gibt und die Ansible-Rolle in einen Operator umgeschrieben. Dieser Operator erm\u00f6glicht es, im Kubernetes-Cluster ein Objekt zu erstellen, das als Kommando bezeichnet wird. Innerhalb des Kommandos erm\u00f6glicht es, in YAML die Umgebung f\u00fcr dieses Kommando zu beschreiben. Und innerhalb der Umgebung des Kommandos erlaubt es zu beschreiben, welche Ressourcen wir zuweisen. <\/p>\n
    <\/p>\n
    Klein eine Erleichterung dieses komplexen Prozesses<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Und abschlie\u00dfend. Was soll man mit alldem tun?
    \nErstens. Pod Security Policy \u2014 das ist gut. Und obwohl keiner der Kubernetes Installer sie bis heute verwendet, sollten sie in Ihren Clustern verwendet werden. <\/p>\n
    <\/p>\n
    Network Policy \u2014 das ist keine weitere unn\u00f6tige Funktion. Das ist es, was im Cluster tats\u00e4chlich ben\u00f6tigt wird. <\/p>\n
    <\/p>\n
    Limit Range\/Resource Quota \u2014 es wird Zeit, das zu verwenden. Wir haben schon lange damit begonnen, und ich war lange \u00fcberzeugt, dass alle das umfassend anwenden. Es stellte sich heraus, dass es eine Seltenheit ist. <\/p>\n
    <\/p>\n
    Neben dem, was ich in meinem Vortrag erw\u00e4hnt habe, gibt es nicht dokumentierte Funktionen, die es erm\u00f6glichen, den Cluster anzugreifen. K\u00fcrzlich ver\u00f6ffentlicht. eine umfassende Analyse der Schwachstellen in Kubernetes<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Einige Dinge sind so traurig und \u00e4rgerlich. Zum Beispiel k\u00f6nnen unter bestimmten Bedingungen die Kubelets im Kubernetes-Cluster den Inhalt des Warlocks-Verzeichnisses an nicht autorisierte Benutzer weitergeben. <\/p>\n
    <\/p>\n
    Hier<\/a><\/noindex> Es gibt Anleitungen, wie man alles reproduzieren kann, was ich beschrieben habe. Dort liegen Dateien mit Produktionsbeispielen, wie ResourceQuota und Pod Security Policy aussehen. Und all dies kann ausprobiert werden. <\/p>\n
    <\/p>\n
    Vielen Dank an alle.<\/p>\n
    Quelle: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
    \u041f\u0430\u0432\u0435\u043b \u0421\u0435\u043b\u0438\u0432\u0430\u043d\u043e\u0432, \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u043e\u0440 \u0440\u0435\u0448\u0435\u043d\u0438\u0439 Southbridge \u0438 \u043f\u0440\u0435\u043f\u043e\u0434\u0430\u0432\u0430\u0442\u0435\u043b\u044c \u0421\u043b\u0451\u0440\u043c\u0430, \u0432\u044b\u0441\u0442\u0443\u043f\u0438\u043b \u0441 \u0434\u043e\u043a\u043b\u0430\u0434\u043e\u043c \u043d\u0430 DevOpsConf 2019. \u042d\u0442\u043e\u0442 \u0434\u043e\u043a\u043b\u0430\u0434 \u2014 \u0447\u0430\u0441\u0442\u044c \u043e\u0434\u043d\u043e\u0439 \u0438\u0437 \u0442\u0435\u043c \u0443\u0433\u043b\u0443\u0431\u043b\u0435\u043d\u043d\u043e\u0433\u043e \u043a\u0443\u0440\u0441\u0430 \u043f\u043e Kubernetes \u00ab\u0421\u043b\u0451\u0440\u043c \u041c\u0435\u0433\u0430\u00bb. \u0421\u043b\u0451\u0440\u043c \u0411\u0430\u0437\u043e\u0432\u044b\u0439: \u0432\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 Kubernetes \u043f\u0440\u043e\u0445\u043e\u0434\u0438\u0442 \u0432 \u041c\u043e\u0441\u043a\u0432\u0435 18-20 \u043d\u043e\u044f\u0431\u0440\u044f. \u0421\u043b\u0451\u0440\u043c \u041c\u0435\u0433\u0430: \u0437\u0430\u0433\u043b\u044f\u0434\u044b\u0432\u0430\u0435\u043c \u043f\u043e\u0434 \u043a\u0430\u043f\u043e\u0442 Kubernetes \u2014 \u041c\u043e\u0441\u043a\u0432\u0430, 22-24 \u043d\u043e\u044f\u0431\u0440\u044f. \u0421\u043b\u0451\u0440\u043c \u041e\u043d\u043b\u0430\u0439\u043d: \u043e\u0431\u0430 \u043a\u0443\u0440\u0441\u0430 \u043f\u043e Kubernetes \u0434\u043e\u0441\u0442\u0443\u043f\u0435\u043d \u0432\u0441\u0435\u0433\u0434\u0430. […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29423,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-39203","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Wir schlie\u00dfen die L\u00fccken im Kubernetes-Cluster. Vortrag und Transkript von DevOpsConf | ProHoster","description":"Pawel Selivanov, L\u00f6sungsarchitekt bei Southbridge und Dozent bei Slurm, hielt einen Vortrag auf der DevOpsConf 2019.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0417\u0430\u0434\u0435\u043b\u044b\u0432\u0430\u0435\u043c \u0434\u044b\u0440\u044b \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435 Kubernetes. \u0414\u043e\u043a\u043b\u0430\u0434 \u0438 \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u0430 \u0441 DevOpsConf | ProHoster","og:description":"\u041f\u0430\u0432\u0435\u043b \u0421\u0435\u043b\u0438\u0432\u0430\u043d\u043e\u0432, \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u043e\u0440 \u0440\u0435\u0448\u0435\u043d\u0438\u0439 Southbridge \u0438 \u043f\u0440\u0435\u043f\u043e\u0434\u0430\u0432\u0430\u0442\u0435\u043b\u044c \u0421\u043b\u0451\u0440\u043c\u0430, \u0432\u044b\u0441\u0442\u0443\u043f\u0438\u043b \u0441 \u0434\u043e\u043a\u043b\u0430\u0434\u043e\u043c \u043d\u0430 DevOpsConf 2019.","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:28:25+00:00","article:modified_time":"2019-10-31T19:28:25+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"39203","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 01:15:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:54:43","updated":"2026-01-24 01:15:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/39203","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=39203"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/39203\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/29423"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=39203"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=39203"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=39203"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}