{"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\/fr\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","title":{"rendered":"Nous r\u00e9parons les failles dans le cluster Kubernetes. Rapport et transcription de DevOpsConf","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pavel Selivanov, architect des solutions chez Southbridge et instructeur de Slurm, a pr\u00e9sent\u00e9 une conf\u00e9rence \u00e0 DevOpsConf 2019. Cette conf\u00e9rence fait partie d'un des sujets approfondis du cours sur Kubernetes \u00ab Slurm Mega \u00bb.<\/p>\n

<\/p>\n

Slurm Basique : introduction \u00e0 Kubernetes<\/a><\/noindex> se d\u00e9roule \u00e0 Moscou du 18 au 20 novembre.
\nSlurm Mega : plongeons sous le capot de Kubernetes<\/a><\/noindex> \u2014 Moscou, du 22 au 24 novembre.
\nSlurm En Ligne : les deux cours sur Kubernetes<\/a><\/noindex> sont toujours disponibles.<\/p>\n

\n

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

Sous le lien \u2014 transcription de la conf\u00e9rence.<\/p>\n

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

Bonjour \u00e0 tous, coll\u00e8gues et sympathisants. Aujourd'hui, je vais parler de la s\u00e9curit\u00e9.<\/p>\n

<\/p>\n

Je constate qu'il y a beaucoup de sp\u00e9cialistes de la s\u00e9curit\u00e9 dans la salle aujourd'hui. Je m'excuse \u00e0 l'avance si j'utilise des termes du domaine de la s\u00e9curit\u00e9 qui ne sont pas conformes \u00e0 vos habitudes. <\/p>\n

<\/p>\n

Il se trouve qu'il y a environ six mois, j'ai eu entre les mains un cluster Kubernetes public. Public \u2014 cela signifie qu'il y a un certain nombre d'espaces de noms, dans lesquels il y a des utilisateurs, isol\u00e9s dans leur propre espace de noms. Tous ces utilisateurs appartiennent \u00e0 diff\u00e9rentes entreprises. Eh bien, il \u00e9tait pr\u00e9vu d'utiliser ce cluster comme CDN. C'est-\u00e0-dire qu'on vous donne un cluster, on vous attribue un utilisateur, vous arrivez dans votre espace de noms et d\u00e9ployez vos frontaux. <\/p>\n

<\/p>\n

Ma pr\u00e9c\u00e9dente entreprise a tent\u00e9 de vendre un tel service. Et on m'a demand\u00e9 de tester le cluster pour voir si cette solution convenait ou non. <\/p>\n

<\/p>\n

Je suis donc arriv\u00e9 dans ce cluster. On m'a donn\u00e9 des droits limit\u00e9s, un espace de noms limit\u00e9. Les personnes l\u00e0-bas comprenaient ce qu'\u00e9tait la s\u00e9curit\u00e9. Ils savaient ce qu'\u00e9tait le contr\u00f4le d'acc\u00e8s bas\u00e9 sur les r\u00f4les (RBAC) dans Kubernetes \u2014 et ils l'ont configur\u00e9 de telle sorte que je ne pouvais pas ex\u00e9cuter des pods s\u00e9par\u00e9ment des d\u00e9ploiements. Je ne me souviens pas de la t\u00e2che que j'essayais de r\u00e9soudre en lan\u00e7ant un pod sans d\u00e9ploiement, mais j'avais tr\u00e8s envie de lancer simplement un pod. J'ai d\u00e9cid\u00e9 par chance de v\u00e9rifier quels droits j'avais dans le cluster, ce que je pouvais faire, ce que je ne pouvais pas faire, ce qu'ils avaient configur\u00e9. J'en profiterai aussi pour expliquer ce qui n'est pas configur\u00e9 correctement dans leur RBAC. <\/p>\n

<\/p>\n

Il s'est av\u00e9r\u00e9 qu'apr\u00e8s deux minutes, j'ai obtenu les droits d'administrateur sur leur cluster, j'ai regard\u00e9 dans tous les espaces de noms voisins et j'ai vu des frontaux de production en cours d'ex\u00e9cution, provenant d'entreprises qui avaient d\u00e9j\u00e0 achet\u00e9 le service et s'\u00e9taient d\u00e9ploy\u00e9es. J'ai failli me retenir de venir sur le front de quelqu'un et de mettre un mot vulgaire sur la page d'accueil. <\/p>\n

<\/p>\n

Je vais expliquer avec des exemples comment j'ai fait cela et comment s'en prot\u00e9ger. <\/p>\n

<\/p>\n

Mais d'abord, permettez-moi de me pr\u00e9senter. Je m'appelle Pavel Selivanov. Je suis architecte chez Southbridge. Je m'y connais en Kubernetes, DevOps et dans les derni\u00e8res technologies tendances. Mes coll\u00e8gues ing\u00e9nieurs chez Southbridge s'occupent de tout cela, et je fais office de consultant. <\/p>\n

<\/p>\n

En plus de notre activit\u00e9 principale, nous avons r\u00e9cemment lanc\u00e9 des projets appel\u00e9s Slurm. Nous essayons de partager notre expertise sur Kubernetes avec le grand public et d'apprendre \u00e0 d'autres \u00e0 utiliser K8s. <\/p>\n

<\/p>\n

De quoi je vais parler aujourd'hui. Le sujet de ma pr\u00e9sentation est \u00e9vident \u2014 la s\u00e9curit\u00e9 des clusters Kubernetes. Mais je tiens \u00e0 pr\u00e9ciser que c'est un sujet tr\u00e8s vaste \u2014 et donc je vais tout de suite dire ce dont je ne parlerai pas. Je ne vais pas aborder les termes d\u00e9j\u00e0 mille fois vus sur Internet, comme le RBAC et les certificats. <\/p>\n

<\/p>\n

Je vais parler de ce qui nous pr\u00e9occupe, mes coll\u00e8gues et moi, en ce qui concerne la s\u00e9curit\u00e9 des clusters Kubernetes. Nous voyons ces probl\u00e8mes chez les fournisseurs de clusters Kubernetes et chez les clients qui viennent \u00e0 nous. M\u00eame chez les clients qui viennent d'autres entreprises de consulting en administration. En r\u00e9alit\u00e9, l'ampleur du probl\u00e8me est \u00e9norme. <\/p>\n

<\/p>\n

Je vais aborder trois points aujourd'hui : <\/p>\n

<\/p>\n

    \n
  1. Les droits des utilisateurs vs les droits des pods. Les droits des utilisateurs et les droits des pods ne sont pas la m\u00eame chose. <\/li>\n
  2. Collecte d'informations sur le cluster. Je montrerai comment il est possible de recueillir toutes les informations n\u00e9cessaires sur un cluster sans avoir de droits particuliers. <\/li>\n
  3. Attaque DoS sur le cluster. Si nous ne pouvons pas collecter d'informations, nous pouvons n\u00e9anmoins rendre le cluster inutilisable. Je parlerai des attaques DoS sur les composants de gestion du cluster. <\/li>\n<\/ol>\n

    <\/p>\n

    Une autre chose g\u00e9n\u00e9rale que je mentionnerai \u2014 sur quoi j'ai test\u00e9 tout \u00e7a, sur quoi je peux affirmer que cela fonctionne.<\/p>\n

    <\/p>\n

    Nous prenons comme base l'installation d'un cluster Kubernetes via Kubespray. Pour ceux qui ne le savent pas, c'est en fait un ensemble de r\u00f4les pour Ansible. Nous l'utilisons constamment dans notre travail. C'est bien car on peut l'installer n'importe o\u00f9 \u2014 que ce soit sur du mat\u00e9riel ou dans le cloud. Une m\u00e9thode d'installation convient en principe \u00e0 tout. <\/p>\n

    <\/p>\n

    Dans ce cluster, j'aurai Kubernetes v1.14.5. L'ensemble du cluster Kube que nous allons examiner est divis\u00e9 en espaces de noms, chaque espace de noms appartenant \u00e0 une \u00e9quipe distincte, avec acc\u00e8s uniquement pour les membres de cette \u00e9quipe. Ils ne peuvent pas entrer dans d'autres espaces de noms, seulement dans le leur. Il existe cependant un compte administrateur qui a des droits sur l'ensemble du cluster. <\/p>\n

    <\/p>\n

    \"Nous<\/p>\n

    <\/p>\n

    J'avais promis que notre premi\u00e8re \u00e9tape serait d'obtenir les droits d'administration sur le cluster. Nous avons besoin d'un pod sp\u00e9cialement pr\u00e9par\u00e9 qui va compromettre le cluster Kubernetes. Tout ce que nous avons \u00e0 faire, c'est de l'appliquer au cluster Kubernetes. <\/p>\n

    <\/p>\n

    kubectl apply -f pod.yaml<\/code><\/pre>\n
    <\/p>\n
    Ce pod atterrira sur l'un des ma\u00eetres du cluster Kubernetes. Ensuite, le cluster nous renverra joyeusement un fichier nomm\u00e9 admin.conf. Ce fichier contient tous les certificats de l'administrateur, ainsi que la configuration de l'API du cluster. Voil\u00e0 comment on peut facilement obtenir un acc\u00e8s administratif, je pense que cela fonctionne pour 98 % des clusters Kubernetes. <\/p>\n
    <\/p>\n
    Je le r\u00e9p\u00e8te, ce pod a \u00e9t\u00e9 cr\u00e9\u00e9 par un d\u00e9veloppeur dans votre cluster, qui a la possibilit\u00e9 de d\u00e9ployer ses propositions dans un petit espace de noms, tout en \u00e9tant limit\u00e9 par RBAC. Il n'avait aucun droit particulier. Cependant, le certificat est quand m\u00eame revenu. <\/p>\n
    <\/p>\n
    \u00c0 pr\u00e9sent, parlons du pod sp\u00e9cialement pr\u00e9par\u00e9. Nous le lan\u00e7ons sur n'importe quelle image. Par exemple, utilisons debian:jessie. <\/p>\n
    <\/p>\n
    Nous avons cette configuration : <\/p>\n
    <\/p>\n
    tolerations:\n-   effect: NoSchedule \n    operator: Exists \nnodeSelector: \n    node-role.kubernetes.io\/master: \"\" <\/code><\/pre>\n
    <\/p>\n
    Qu'est-ce qu'une tol\u00e9rance ? Les ma\u00eetres dans le cluster Kubernetes sont g\u00e9n\u00e9ralement marqu\u00e9s par une caract\u00e9ristique appel\u00e9e taint (\"contamination\" en anglais). L'id\u00e9e de cette \"contamination\" est qu'aucun pod ne peut \u00eatre affect\u00e9 aux n\u0153uds ma\u00eetres. Mais rien n'emp\u00eache un pod d'indiquer qu'il est tol\u00e9rant \u00e0 cette \"contamination\". La section Toleration indique justement que si un certain n\u0153ud a NoSchedule, alors notre pod est tol\u00e9rant \u00e0 cette contamination - et il n'y a aucun probl\u00e8me. <\/p>\n
    <\/p>\n
    Ensuite, nous pr\u00e9cisons que notre pod n'est pas seulement tol\u00e9rant, mais qu'il souhaite en fait \u00eatre affect\u00e9 sp\u00e9cifiquement \u00e0 un ma\u00eetre. Parce que sur les ma\u00eetres se trouvent les \u00e9l\u00e9ments les plus pr\u00e9cieux dont nous avons besoin - tous les certificats. Nous sp\u00e9cifions donc nodeSelector - et nous avons une \u00e9tiquette standard sur les ma\u00eetres qui permet de s\u00e9lectionner parmi tous les n\u0153uds du cluster ceux qui sont des ma\u00eetres. <\/p>\n
    <\/p>\n
    Avec ces deux sections, le pod arrivera certainement sur le ma\u00eetre. Et il sera autoris\u00e9 \u00e0 y r\u00e9sider. <\/p>\n
    <\/p>\n
    Mais simplement arriver sur le ma\u00eetre ne suffit pas. Cela ne nous apportera rien. Donc, plus loin, nous avons ces deux \u00e9l\u00e9ments :<\/p>\n
    <\/p>\n
    hostNetwork: true \nhostPID: true <\/code><\/pre>\n
    <\/p>\n
    Nous indiquons que notre pod, que nous d\u00e9ployons, vivra dans l'espace de noms du n\u0153ud, dans l'espace de noms r\u00e9seau et dans l'espace de noms PID. Une fois le pod lanc\u00e9 sur le ma\u00eetre, il pourra voir toutes les interfaces r\u00e9elles et vivantes de ce n\u0153ud, \u00e9couter tout le trafic et voir les PID de tous les processus.<\/p>\n
    <\/p>\n
    Ensuite, il ne reste plus qu'\u00e0 prendre etcd et \u00e0 lire ce que vous voulez. <\/p>\n
    <\/p>\n
    Le plus int\u00e9ressant est cette fonctionnalit\u00e9 de Kubernetes qui est pr\u00e9sente par d\u00e9faut. <\/p>\n
    <\/p>\n
    volumeMounts:\n- mountPath: \/host \n  name: host \nvolumes:\n- hostPath: \n    path: \/ \n    type: Directory \n  name: host <\/code><\/pre>\n
    <\/p>\n
    Et l'essence de cette fonctionnalit\u00e9 est que nous pouvons, dans le pod que nous lan\u00e7ons, m\u00eame sans droits sur ce cluster, sp\u00e9cifier que nous voulons cr\u00e9er un volume de type hostPath. Cela signifie prendre un chemin depuis l'h\u00f4te sur lequel nous allons nous ex\u00e9cuter \u2014 et le prendre comme volume. Et ensuite, nous le nommons name: host. Ce hostPath est mont\u00e9 \u00e0 l'int\u00e9rieur du pod. Dans cet exemple, dans le r\u00e9pertoire \/host. <\/p>\n
    <\/p>\n
    Je r\u00e9p\u00e8te encore une fois. Nous avons dit au pod d'arriver sur le ma\u00eetre, d'obtenir hostNetwork et hostPID \u2014 et de monter tout le root du ma\u00eetre \u00e0 l'int\u00e9rieur de ce pod. <\/p>\n
    <\/p>\n
    Vous comprenez qu'au niveau de Debian, nous avons un bash qui s'ex\u00e9cute en tant que root. Cela signifie que nous venons d'obtenir les privil\u00e8ges root sur le ma\u00eetre, sans avoir de droits dans le cluster Kubernetes.<\/p>\n
    <\/p>\n
    La t\u00e2che suivante consiste \u00e0 entrer dans le pod dans le r\u00e9pertoire \/host \/etc\/kubernetes\/pki, si je ne me trompe pas, et \u00e0 r\u00e9cup\u00e9rer tous les certificats du ma\u00eetre du cluster et, par cons\u00e9quent, \u00e0 devenir l'administrateur du cluster. <\/p>\n
    <\/p>\n
    Si on y regarde de plus pr\u00e8s, ce sont quelques-unes des permissions les plus dangereuses dans les pods \u2014 peu importe les droits de l'utilisateur :
    \n\"Nous<\/p>\n
    <\/p>\n
    Si j'ai le droit de lancer un pod dans un espace de noms du cluster, alors ce pod a ces droits par d\u00e9faut. Je peux lancer des pods privil\u00e9gi\u00e9s, et cela signifie pratiquement avoir tous les droits, presque un acc\u00e8s root sur le n\u0153ud. <\/p>\n
    <\/p>\n
    Mon pr\u00e9f\u00e9r\u00e9 \u2014 l'utilisateur root. Et Kubernetes a cette option Ex\u00e9cuter En Tant Que Non-Root. C'est une sorte de protection contre les hackers. Savez-vous ce qu'est un \u00ab virus moldave \u00bb ? Si vous \u00eates un hacker et que vous venez dans mon cluster Kubernetes, alors nous, pauvres administrateurs, vous demandons : \u00ab Veuillez indiquer, s'il vous pla\u00eet, dans vos pods, par lesquels vous allez pirater mon cluster, ex\u00e9cuter en tant que non-root. Sinon, vous risquez de lancer un processus dans votre pod sous root, et il vous sera tr\u00e8s facile de me pirater. Prot\u00e9gez-vous, s'il vous pla\u00eet, vous-m\u00eame \u00bb. <\/p>\n
    <\/p>\n
    Le volume host path \u2014 \u00e0 mon avis, c'est le moyen le plus rapide d'obtenir le r\u00e9sultat souhait\u00e9 du cluster Kubernetes. <\/p>\n
    <\/p>\n
    Mais que faire avec tout cela ? <\/p>\n
    <\/p>\n
    Une r\u00e9flexion qui devrait venir \u00e0 l'esprit de tout administrateur normal confront\u00e9 \u00e0 Kubernetes : \u00ab Ah, je l'avais dit, Kubernetes ne fonctionne pas. Il a des failles. Et tout \u00e7a, c'est nul \u00bb. En r\u00e9alit\u00e9, il existe un truc qu'on appelle la documentation, et si l'on y jette un coup d'\u0153il, il y a une section la Politique de S\u00e9curit\u00e9 des Pods<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    C'est un objet yaml \u2014 que nous pouvons cr\u00e9er dans un cluster Kubernetes \u2014 qui contr\u00f4le les aspects de s\u00e9curit\u00e9 sp\u00e9cifiquement dans la description des pods. Autrement dit, il contr\u00f4le effectivement les droits d'utilisation de divers hostNetwork, hostPID, et certains types de volumes qui existent dans les pods lors du d\u00e9marrage. Avec la Pod Security Policy, tout cela peut \u00eatre d\u00e9crit. <\/p>\n
    <\/p>\n
    Ce qui est int\u00e9ressant dans la Pod Security Policy, c'est que dans le cluster Kubernetes, tous les installateurs de PSP ne sont pas d\u00e9finis, ils sont tout simplement d\u00e9sactiv\u00e9s par d\u00e9faut. La Pod Security Policy s'active gr\u00e2ce \u00e0 un plugin d'admission.<\/p>\n
    <\/p>\n
    D'accord, d\u00e9ployons la Pod Security Policy dans le cluster, disons que nous avons certains pods de service dans un namespace, auxquels seuls les administrateurs ont acc\u00e8s. Disons que dans tous les autres pods, les droits sont limit\u00e9s. Parce qu'il est probable que les d\u00e9veloppeurs n'ont pas besoin de lancer des pods privil\u00e9gi\u00e9s dans votre cluster. <\/p>\n
    <\/p>\n
    Et il semblerait que tout va bien. Et notre cluster Kubernetes ne peut pas \u00eatre compromis en deux minutes. <\/p>\n
    <\/p>\n
    Il y a un probl\u00e8me. Tr\u00e8s probablement, si vous avez un cluster Kubernetes, un syst\u00e8me de surveillance est install\u00e9 dans votre cluster. Je parie m\u00eame que si votre cluster a une surveillance, elle s'appelle Prometheus. <\/p>\n
    <\/p>\n
    Ce que je vais dire maintenant sera valable aussi bien pour l'op\u00e9rateur Prometheus que pour Prometheus install\u00e9 dans sa forme pure. La question est que si je ne peux pas obtenir rapidement un administrateur dans le cluster, cela signifie que je dois chercher davantage. Et je peux chercher \u00e0 l'aide de votre surveillance.<\/p>\n
    <\/p>\n
    Il est probable que tout le monde ait lu les m\u00eames articles sur Habr\u00e9, et que la surveillance se trouve dans le namespace monitoring. Le chart Helm de tout le monde s'appelle \u00e0 peu pr\u00e8s de la m\u00eame mani\u00e8re. Je suppose que si vous faites helm install stable\/prometheus, vous obtiendrez des noms \u00e0 peu pr\u00e8s similaires. Et il est m\u00eame probable que je n'aurai pas \u00e0 deviner le nom DNS dans votre cluster. Parce qu'il est standard. <\/p>\n
    <\/p>\n
    \"Nous<\/p>\n
    <\/p>\n
    Ensuite, nous avons un namespace dev, dans lequel nous pouvons lancer un pod. Et ensuite, \u00e0 partir de ce pod, il est tr\u00e8s facile de faire cela : <\/p>\n
    <\/p>\n
    $ curl http:\/\/prometheus-kube-state-metrics.monitoring <\/code><\/pre>\n
    <\/p>\n
    prometheus-kube-state-metrics est l'un des exporters de Prometheus, qui collecte des m\u00e9triques depuis l'API de Kubernetes lui-m\u00eame. Il y a beaucoup de donn\u00e9es sur ce qui est en cours d'ex\u00e9cution dans votre cluster, ce que c'est, et quels probl\u00e8mes vous pourriez rencontrer. <\/p>\n
    <\/p>\n
    Prenons un exemple simple : <\/p>\n
    <\/p>\n
    kube_pod_container_info{namespace=\u00abkube-system\u00bb,pod=\u00abkube-apiserver-k8s-1\u00bb,container=\u00abkube-apiserver\u00bb,image= <\/p>\n
    <\/p>\n
    \u00abgcr.io\/google-containers\/kube-apiserver:v1.14.5\u00bb <\/strong><\/p>\n
    <\/p>\n
    ,image_id=\u00abdocker-pullable:\/\/gcr.io\/google-containers\/kube-apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a9638ee634989\u00bb,container_id=\u00abdocker:\/\/7cbe7b1fea33f811fdd8f7e0e079191110268f2853397d7daf08e72c22d3cf8b\u00bb} 1 <\/p>\n
    <\/p>\n
    En effectuant une simple requ\u00eate curl depuis un pod non privil\u00e9gi\u00e9, vous pouvez obtenir ce genre d'informations. Si vous ne savez pas quelle version de Kubernetes vous ex\u00e9cutez, elle vous le dira facilement. <\/p>\n
    <\/p>\n
    Et ce qui est le plus int\u00e9ressant, c'est qu'en plus d'appeler kube-state-metrics, vous pouvez \u00e9galement vous adresser directement \u00e0 Prometheus. Vous pouvez collecter des m\u00e9triques de l\u00e0-bas. Th\u00e9oriquement, vous pouvez m\u00eame construire une requ\u00eate depuis le cluster vers Prometheus qui pourrait simplement le d\u00e9sactiver. Et votre surveillance cesserait compl\u00e8tement de fonctionner dans le cluster. <\/p>\n
    <\/p>\n
    La question se pose alors : est-ce qu'une surveillance externe surveille votre surveillance ? Je viens d'acqu\u00e9rir la possibilit\u00e9 d'agir dans le cluster Kubernetes sans aucune cons\u00e9quences. Vous ne saurez m\u00eame pas que j'agis l\u00e0-bas, car la surveillance n'existe d\u00e9j\u00e0 plus. <\/p>\n
    <\/p>\n
    Tout comme avec les PSP, on a l'impression que le probl\u00e8me vient de ces technologies \u00e0 la mode \u2014 Kubernetes, Prometheus \u2014 qui semblent ne pas fonctionner et \u00eatre pleines de failles. En r\u00e9alit\u00e9, ce n'est pas le cas. <\/p>\n
    <\/p>\n
    Il existe une chose \u2014 Network Policy<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    Si vous \u00eates un administrateur raisonnable, vous savez probablement que Network Policy est un autre yaml, qu'il y en a d\u00e9j\u00e0 beaucoup dans le cluster. Et certaines politiques de r\u00e9seau ne sont s\u00fbrement pas n\u00e9cessaires. Et m\u00eame si vous avez lu ce qu'est une Network Policy, que c'est un pare-feu yaml de Kubernetes qui permet de restreindre les droits d'acc\u00e8s entre les namespaces, entre les pods, vous avez s\u00fbrement d\u00e9cid\u00e9 que le pare-feu au format yaml dans Kubernetes rel\u00e8ve simplement d'abstractions suppl\u00e9mentaires... Non, ce n'est d\u00e9finitivement pas n\u00e9cessaire. <\/p>\n
    <\/p>\n
    M\u00eame si vos experts en s\u00e9curit\u00e9 ne vous ont pas inform\u00e9 qu'il est tr\u00e8s facile de construire un pare-feu avec votre Kubernetes, et qu'il peut \u00eatre tr\u00e8s granulaire. S'ils ne le savent pas encore et ne vous sollicitent pas : \u00ab Allez, donnez, donnez\u2026 \u00bb Dans tous les cas, vous aurez besoin des Network Policies pour restreindre l'acc\u00e8s \u00e0 certains espaces serveurs qui peuvent \u00eatre sollicit\u00e9s depuis votre cluster sans aucune autorisation. <\/p>\n
    <\/p>\n
    Comme dans l'exemple que j'ai donn\u00e9, il est possible d'acc\u00e9der aux kube state metrics de n'importe quel namespace dans le cluster Kubernetes sans avoir de droits. Les politiques r\u00e9seau ont bloqu\u00e9 l'acc\u00e8s depuis tous les autres namespaces vers le namespace de surveillance, et voil\u00e0 : pas d'acc\u00e8s, pas de probl\u00e8me. Dans tous les charts disponibles, tant dans le Prometheus standard que dans celui d\u00e9di\u00e9 \u00e0 l'op\u00e9rateur, il suffit d'activer l'option pour les policies r\u00e9seau dans les valeurs Helm. Il suffit d'activer cela, et elles fonctionneront. <\/p>\n
    <\/p>\n
    Il y a n\u00e9anmoins un probl\u00e8me. En tant qu'administrateur raisonnable, vous avez probablement d\u00e9cid\u00e9 que les policies r\u00e9seau n'\u00e9taient pas n\u00e9cessaires. Et apr\u00e8s avoir lu plusieurs articles sur des ressources comme Habr, vous avez conclu que flannel, surtout en mode host-gateway, est la meilleure option que vous puissiez choisir. <\/p>\n
    <\/p>\n
    Que faire ? <\/p>\n
    <\/p>\n
    Vous pouvez essayer de red\u00e9ployer la solution r\u00e9seau que vous avez dans votre cluster Kubernetes et la remplacer par quelque chose de plus fonctionnel. Par exemple, Calico. Mais je veux tout de suite dire que changer la solution r\u00e9seau dans un cluster Kubernetes en fonctionnement est assez complexe. Je l'ai r\u00e9solu deux fois (dans les deux cas, cependant, th\u00e9oriquement), mais nous avons m\u00eame montr\u00e9 comment le faire lors des Slurm. Pour nos \u00e9tudiants, nous avons montr\u00e9 comment changer la solution r\u00e9seau dans un cluster Kubernetes. En principe, vous pouvez essayer de le faire de telle mani\u00e8re qu'il n'y ait pas de temps d'arr\u00eat sur le cluster de production. Mais il est probable que cela ne fonctionne pas. <\/p>\n
    <\/p>\n
    Et le probl\u00e8me se r\u00e9sout en fait tr\u00e8s simplement. Il y a des certificats dans le cluster, et vous savez que vos certificats vont expirer dans un an. Eh bien, la solution normale avec les certificats dans le cluster est : pourquoi s'emb\u00eater, nous allons simplement mettre en place un nouveau cluster \u00e0 c\u00f4t\u00e9, laissant l'ancien expirer, et nous d\u00e9ploierons tout de nouveau. Certes, lorsque l'ancien expirera, il sera hors service pendant une journ\u00e9e, mais au moins, nous aurons un nouveau cluster. <\/p>\n
    <\/p>\n
    Lorsque vous mettrez en place un nouveau cluster, n\u2019oubliez pas d\u2019int\u00e9grer Calico au lieu de flannel. <\/p>\n
    <\/p>\n
    Que faire si vos certificats sont valables pour cent ans et que vous ne pr\u00e9voyez pas de red\u00e9ployer le cluster ? Il existe un outil appel\u00e9 Kube-RBAC-Proxy. C'est un d\u00e9veloppement tr\u00e8s int\u00e9ressant qui permet de s'int\u00e9grer, en tant que conteneur sidecar, \u00e0 n'importe quel pod dans un cluster Kubernetes. Il ajoute en fait une autorisation via RBAC de Kubernetes \u00e0 ce pod. <\/p>\n
    <\/p>\n
    Il y a un probl\u00e8me. Auparavant, dans l'op\u00e9rateur Prometheus, cette solution Kube-RBAC-Proxy \u00e9tait int\u00e9gr\u00e9e. Mais ce n'est plus le cas. Les versions modernes reposent sur le fait que vous avez une politique r\u00e9seau et que vous les utilisez pour bloquer l'acc\u00e8s. Par cons\u00e9quent, il faudra l\u00e9g\u00e8rement modifier le chart. En fait, si vous allez dans ce d\u00e9p\u00f4t<\/a><\/noindex>, il y a des exemples d'utilisation en tant que sidecars, et il faudra modifier le chart au minimum. <\/p>\n
    <\/p>\n
    Il y a aussi un petit autre probl\u00e8me. Ce n'est pas seulement Prometheus qui expose ses m\u00e9triques \u00e0 tout le monde. Tous nos composants du cluster Kubernetes peuvent \u00e9galement fournir leurs propres m\u00e9triques. <\/p>\n
    <\/p>\n
    Mais comme je l'ai d\u00e9j\u00e0 dit, si vous ne pouvez pas acc\u00e9der au cluster et collecter des informations, vous pouvez au moins causer des probl\u00e8mes. <\/p>\n
    <\/p>\n
    Je vais donc rapidement vous montrer deux fa\u00e7ons de nuire \u00e0 la sant\u00e9 d'un cluster Kubernetes. <\/p>\n
    <\/p>\n
    Vous allez rire lorsque je vais vous en parler, ce sont deux cas de la vie r\u00e9elle. <\/p>\n
    <\/p>\n
    Premi\u00e8re m\u00e9thode. \u00c9puisement des ressources. <\/p>\n
    <\/p>\n
    Nous allons lancer un autre pod sp\u00e9cial. Il aura une section comme celle-ci. <\/p>\n
    <\/p>\n
    resources: \n    requests: \n        cpu: 4 \n        memory: 4Gi <\/code><\/pre>\n
    <\/p>\n
    Comme vous le savez, les requests correspondent \u00e0 la quantit\u00e9 de CPU et de m\u00e9moire qui est r\u00e9serv\u00e9e pour des pods sp\u00e9cifiques avec des requests. Si nous avons un h\u00f4te \u00e0 quatre c\u0153urs dans le cluster Kubernetes, et qu'un pod arrive avec des requests de quatre CPUs, cela signifie qu'aucun autre pod avec des requests ne pourra arriver sur cet h\u00f4te. <\/p>\n
    <\/p>\n
    Si je lance un tel pod, puis que je fais la commande : <\/p>\n
    <\/p>\n
    $ kubectl scale special-pod --replicas=...<\/code><\/pre>\n
    <\/p>\n
    Alors personne ne pourra se d\u00e9ployer dans le cluster Kubernetes. Parce que toutes les nodes seront \u00e0 court de requests. De cette mani\u00e8re, j'arr\u00eaterai votre cluster Kubernetes. Si je fais cela le soir, je peux arr\u00eater les d\u00e9ploiements pendant un bon moment. <\/p>\n
    <\/p>\n
    Si nous consultons \u00e0 nouveau la documentation de Kubernetes, nous y trouverons un concept appel\u00e9 Limit Range. Il d\u00e9finit les ressources pour les objets du cluster. Vous pouvez \u00e9crire un objet Limit Range en YAML, l'appliquer \u00e0 certains espaces de noms \u2014 et ensuite, dans cet espace de noms, vous pouvez sp\u00e9cifier que vous avez des ressources par d\u00e9faut, maximales et minimales pour les pods.<\/p>\n
    <\/p>\n
    Avec cette fonctionnalit\u00e9, nous pouvons limiter les utilisateurs dans des espaces de noms de produits sp\u00e9cifiques en ce qui concerne leurs capacit\u00e9s \u00e0 indiquer certaines choses sur leurs pods. Mais malheureusement, m\u00eame si vous dites \u00e0 l'utilisateur qu'il ne doit pas lancer de pods avec des requ\u00eates sup\u00e9rieures \u00e0 un CPU, il existe une commande fantastique pour le scale, ou bien \u00e0 travers le tableau de bord, ils peuvent effectuer un scale.<\/p>\n
    <\/p>\n
    Et de l\u00e0 d\u00e9coule la deuxi\u00e8me m\u00e9thode. Lan\u00e7ons 11 111 111 111 111 pods. C'est onze milliards. Ce n'est pas que j'ai invent\u00e9 ce nombre, c'est quelque chose que j'ai r\u00e9ellement vu. <\/p>\n
    <\/p>\n
    Une histoire r\u00e9elle. Tard dans la soir\u00e9e, je m'appr\u00eatais \u00e0 quitter le bureau. Je vois dans un coin un groupe de d\u00e9veloppeurs qui s'affairent devant leurs ordinateurs portables. Je m'approche d'eux et je demande : \u00ab Que vous est-il arriv\u00e9 ? \u00bb<\/p>\n
    <\/p>\n
    Un peu plus t\u00f4t, vers neuf heures du soir, l'un des d\u00e9veloppeurs se pr\u00e9parait \u00e0 rentrer chez lui. Il a d\u00e9cid\u00e9 : \u00ab Je vais faire un scale de mon application \u00e0 un \u00bb. Il a appuy\u00e9 sur un, et internet a l\u00e9g\u00e8rement ralenti. Il a de nouveau appuy\u00e9 sur un, a appuy\u00e9 sur un, a cliqu\u00e9 sur Entr\u00e9e. Il a essay\u00e9 tout ce qu'il pouvait. \u00c0 ce moment-l\u00e0, internet s'est r\u00e9veill\u00e9 \u2014 et tout a commenc\u00e9 \u00e0 se mettre \u00e0 l'\u00e9chelle jusqu'\u00e0 ce nombre. <\/p>\n
    <\/p>\n
    En r\u00e9alit\u00e9, cette histoire ne se passait pas sur Kubernetes, \u00e0 l'\u00e9poque c'\u00e9tait Nomad. Cela s'est termin\u00e9 par des heures de tentatives pour arr\u00eater Nomad de ses tentatives obstin\u00e9es de scalabilit\u00e9, Nomad a r\u00e9pondu qu'il ne cesserait pas de scaler et qu'il ne ferait rien d'autre. \u00ab Je suis fatigu\u00e9, je pars. \u00bb Et il s'est repli\u00e9. <\/p>\n
    <\/p>\n
    Naturellement, j'ai essay\u00e9 de faire la m\u00eame chose sur Kubernetes. Onze milliards de pods n'ont pas ravi Kubernetes, il a dit : \u00ab Je ne peux pas. \u00c7a d\u00e9passe les limites internes. \u00bb Mais un milliard de pods a fonctionn\u00e9. <\/p>\n
    <\/p>\n
    En r\u00e9ponse \u00e0 un milliard de pods, il n'est pas entr\u00e9 dans Kubernetes. Il a vraiment commenc\u00e9 \u00e0 s'\u00e9tendre. Plus le processus avan\u00e7ait, plus il lui fallait de temps pour cr\u00e9er de nouveaux pods. Mais le processus avan\u00e7ait toujours. Le seul probl\u00e8me est que si je peux lancer des pods \u00e0 volont\u00e9 dans mon espace de noms, m\u00eame sans requ\u00eates ni limites, je pourrais lancer avec certaines t\u00e2ches un nombre de pods tel que ces t\u00e2ches commenceront \u00e0 saturer les n\u0153uds en m\u00e9moire et en CPU. Lorsque je lance autant de pods, les informations doivent \u00eatre stock\u00e9es, c'est-\u00e0-dire dans etcd. Et quand trop d'informations y entrent, le stockage commence \u00e0 r\u00e9pondre beaucoup trop lentement \u2014 et Kubernetes commence \u00e0 ralentir. <\/p>\n
    <\/p>\n
    Et il y a un autre probl\u00e8me... Comme vous le savez, les composants de gestion de Kubernetes ne sont pas une seule pi\u00e8ce centrale, mais plusieurs composants. Parmi eux se trouvent le contr\u00f4leur de gestion, le planificateur, etc. Tous ces \u00e9l\u00e9ments commenceront \u00e0 travailler simultan\u00e9ment sur des t\u00e2ches inutiles et peu productives, ce qui prendra de plus en plus de temps \u00e0 mesure que le temps passe. Le contr\u00f4leur de gestion cr\u00e9era de nouveaux pods. Le planificateur tentera de leur trouver un nouveau n\u0153ud. Les nouveaux n\u0153uds dans votre cluster seront probablement bient\u00f4t \u00e9puis\u00e9s. Le cluster Kubernetes commencera \u00e0 fonctionner de plus en plus lentement.<\/p>\n
    <\/p>\n
    Mais j'ai d\u00e9cid\u00e9 d'aller encore plus loin. Comme vous le savez, dans Kubernetes, il existe une chose appel\u00e9e service. Eh bien, par d\u00e9faut, dans vos clusters, le service fonctionne probablement avec des IP tables. <\/p>\n
    <\/p>\n
    Si vous lancez un milliard de pods, par exemple, puis que vous forcez Kubernetes \u00e0 cr\u00e9er de nouveaux services avec un script : <\/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
    Sur tous les n\u0153uds du cluster, de nouvelles r\u00e8gles iptables seront g\u00e9n\u00e9r\u00e9es presque simultan\u00e9ment. En effet, pour chaque service, un milliard de r\u00e8gles iptables seront g\u00e9n\u00e9r\u00e9es. <\/p>\n
    <\/p>\n
    J'ai test\u00e9 cela sur quelques milliers, jusqu'\u00e0 une dizaine. Et le probl\u00e8me est qu'\u00e0 ce stade, il devient assez probl\u00e9matique de se connecter en SSH \u00e0 un n\u0153ud. Parce que les paquets, en passant par un tel nombre de cha\u00eenes, ne se comportent pas tr\u00e8s bien. <\/p>\n
    <\/p>\n
    Et tout cela peut \u00e9galement \u00eatre r\u00e9solu \u00e0 l'aide de Kubernetes. Il existe un objet appel\u00e9 Resource quota. Il d\u00e9finit le nombre de ressources et d'objets disponibles pour un namespace dans le cluster. Nous pouvons cr\u00e9er un objet yaml dans chaque namespace du cluster Kubernetes. Gr\u00e2ce \u00e0 cet objet, nous pouvons d\u00e9finir qu'un certain nombre de requ\u00eates et de limites sont allou\u00e9s \u00e0 ce namespace, et nous pouvons ensuite indiquer qu'il est possible de cr\u00e9er 10 services et 10 pods dans ce namespace. Et le d\u00e9veloppeur peut m\u00eame se faire des soucis en soir\u00e9e. Kubernetes lui dira : \u00ab Vous ne pouvez pas augmenter vos pods \u00e0 ce nombre, car cela d\u00e9passe le quota de ressources \u00bb. Voil\u00e0, le probl\u00e8me est r\u00e9solu. La documentation est ici<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    Un probl\u00e8me se pose \u00e0 ce sujet. Vous ressentez \u00e0 quel point il devient difficile de cr\u00e9er un namespace dans Kubernetes. Pour le cr\u00e9er, nous devons tenir compte de beaucoup de choses.<\/p>\n
    <\/p>\n
    Resource quota + Limit Range + RBAC
    \n\u2022 Cr\u00e9ation du namespace
    \n\u2022 Cr\u00e9ation d'une limitrange \u00e0 l'int\u00e9rieur
    \n\u2022 Cr\u00e9ation d'un resourcequota \u00e0 l'int\u00e9rieur
    \n\u2022 Cr\u00e9ation d'un serviceaccount pour CI
    \n\u2022 Cr\u00e9ation d'un rolebinding pour CI et utilisateurs
    \n\u2022 Lancement optionnel des pods de service n\u00e9cessaires <\/p>\n
    <\/p>\n
    C'est pourquoi, profitant de l'occasion, je voudrais partager mes d\u00e9veloppements. Il existe un outil appel\u00e9 op\u00e9rateur SDK. C'est une fa\u00e7on d'\u00e9crire des op\u00e9rateurs pour Kubernetes dans le cluster. Vous pouvez \u00e9crire des op\u00e9rateurs en utilisant Ansible.<\/p>\n
    <\/p>\n
    Au d\u00e9part, nous avions \u00e9crit sur Ansible, puis j'ai vu qu'il existait un op\u00e9rateur SDK et j'ai r\u00e9\u00e9crit le r\u00f4le Ansible en op\u00e9rateur. Cet op\u00e9rateur permet de cr\u00e9er dans le cluster Kubernetes un objet appel\u00e9 commande. \u00c0 l'int\u00e9rieur de cette commande, il permet de d\u00e9crire en yaml l'environnement pour cette commande. Et \u00e0 l'int\u00e9rieur de l'environnement de la commande, il permet de d\u00e9crire combien de ressources nous allouons. <\/p>\n
    <\/p>\n
    Petite facilitation de tout ce processus complexe<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Et en conclusion. Que faire de tout cela ?
    \nD'abord. La Pod Security Policy - c'est bien. Et m\u00eame si aucun des installateurs de Kubernetes ne les utilise encore \u00e0 ce jour, il est n\u00e9anmoins n\u00e9cessaire de les utiliser dans vos clusters. <\/p>\n
    <\/p>\n
    La Network Policy - ce n'est pas une autre fonctionnalit\u00e9 inutile. C'est quelque chose dont on a r\u00e9ellement besoin dans le cluster. <\/p>\n
    <\/p>\n
    LimitRange\/ResourceQuota - il est temps de les utiliser. Nous avons commenc\u00e9 \u00e0 les utiliser depuis longtemps, et j'\u00e9tais convaincu que tout le monde les appliquait. Il s'est av\u00e9r\u00e9 que c'est assez rare. <\/p>\n
    <\/p>\n
    En plus de ce que j'ai mentionn\u00e9 lors de mon discours, il y a des fonctionnalit\u00e9s non document\u00e9es qui permettent d'attaquer le cluster. Cela a \u00e9t\u00e9 r\u00e9cemment publi\u00e9. une grande analyse des vuln\u00e9rabilit\u00e9s de Kubernetes.<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Certaines choses sont tellement tristes et choquantes. Par exemple, dans certaines conditions, les kubelets dans le cluster Kubernetes peuvent exposer le contenu du r\u00e9pertoire des warlocks \u00e0 un utilisateur non autoris\u00e9. <\/p>\n
    <\/p>\n
    Ici<\/a><\/noindex> Il y a des instructions sur la fa\u00e7on de reproduire tout ce que j'ai pr\u00e9sent\u00e9. Il y a des fichiers avec des exemples de production, montrant \u00e0 quoi ressemblent ResourceQuota et Pod Security Policy. Et tout cela peut \u00eatre explor\u00e9. <\/p>\n
    <\/p>\n
    Merci \u00e0 tous.<\/p>\n
    Source : 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\udd47Nous bouchons les failles dans le cluster Kubernetes. Pr\u00e9sentation et transcription de DevOpsConf | ProHoster","description":"Pavel Selivanov, architecte de solutions chez Southbridge et enseignant \u00e0 Slyrma, a pr\u00e9sent\u00e9 une conf\u00e9rence lors de DevOpsConf 2019.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","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\/fr\/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\/fr\/wp-json\/wp\/v2\/posts\/39203","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=39203"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/39203\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/29423"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=39203"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=39203"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=39203"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}