 E aí, pessoal, tudo bem? Compartilhar a minha tela aqui. Pessoal, tá dando pra ver? Tá compartilhando, tá dando pra ver? Vocês não entendem? Então, aí, pessoal, então... Uma honra tá aqui pra poder falar com vocês hoje. Vamos falar hoje, então, sobre o Debra Thunder Routeless. Eu tô muito feliz de estar participando aqui do evento hoje com vocês, esse evento de gigantesco histórico que tá sendo pra Comidade Brasileira de Coventas. Então, vamos começar. Galera, prazer, meu nome é João. Eu sou DevOps Engineer na História Blog. Eu sou entusiasta em segurança da informação em containers. Uma informação curiosa, eu sou um aceiter de container. No começo eu não era muito fã, eu vim de um mundo de segurança e eu migrei a uns 4, 5 anos pra essa lado de DevOps. E fui aí há 4 anos que eu encontrei o Kubernetes e eu juntei minhas duas paixões que viram segurança e Kubernetes e eu consegui juntar esses dois nesse mesmo universo. Qual que vai ser o nosso cronograma aqui hoje? Primeiro, a gente vai recutular o que são containers e name spaces, o que não é Routeless, o que é Routeless, e vantagens e desvantagens desse projeto e a gente vai ver algumas demonstrações também. Então, a primeira coisa que eu queria deixar pra vocês, a primeira mensagem impactante é que todo container por quadrão é executado como Rout. Quando eu falo que é executado como Rout, não é o processo dentro do container, sim, o processo lá no host. Então, o processo, o nosso container runtime, ele tá sim executado como Rout. Então, por padrão, isso é de todos os containers runtime. Isso também se aplica nos componentes de alguns orchestradores, por exemplo, o Kubernetes. Então, a gente tem o Kublet que também roda como Rout. Então, vamos recapitular o que são containers. Container é uma tecnologia que permite a gente pacotar e isolar aplicações com tudo o que ela precisa num único pacote e ela pode ser executada em vários ambientes e ela sendo executada da mesma forma. Então, tá todo dentro daquele pacote, então, é bem essa imagem aqui da direita que a gente vê que tem nossas aplicações e elas estão em cima de uma container engine, elas compartilham o mesmo kernel e tá tudo o que ela precisa tá ali. Então, todos os pacotes e aonde a gente colocar ela vai rodar. Só que isso é uma imagem muito superficial do que realmente acontece lá embaixo. Então, vamos ver o que realmente acontece lá, o que que o sistema operacional vê e como que isso funciona. Então, aqui eu tenho duas imagens. Na imagem da esquerda, eu tô redratando o processo como que o Docker engine trabalha. Então, primeiro, o meu Docker client, quando eu dou um Docker run, alguma coisa, ele fala com a API do Docker, que é o Docker Dimon. O Docker Dimon, ele chama o container G. O container G vai chamar o runC e o runC em si vai executar o nosso container. Ainda tem todo um processo, então, não é o Docker que executa, ele só vai gerenciar um pouco de tudo isso. E aqui na imagem da direita, a gente tem o processo do container G. Ele é um pouco mais rápido, porque ele tem algumas etapas a menos. Então, ele chama direto o runC e o overLFS. E ele, o runC, ele vai chamar os nossos namespaces, capabilites e groups de overLFS. Então, o coração de tudo são os namespaces. Então, agora, vamos entender um pouco mais ainda no detalhe como que funciona isso. Então, aqui eu tenho um parte de um comando e um parte de um log. O que eu tô fazendo aqui? Eu tô dando mais Trace, todas as chamadas de sistema, todas as syscalls que foram feitas pelos processos do container G. Eu tô salvando em si um arquivo chamado GeLog. E aqui embaixo, eu tô executando um Docker run, eu tô chamando um bash, e eu tô pedindo pra ele executar um ec, com a sede de Brasil e um comando ID. Então, aqui, nessas vinhas abaixo, já são o resultado desse comando que eu peguei com a sTrace. Então, nessa, só nessa execução, quase foram 20 melinhas, muito filtrado. Vamos ver o que acontece. Então, aqui, como executando o Docker, ele chamou o Docker string Run C. Ele, o Docker string Run C, chamou o container G. Então, aqui, é usado dos processos também. O Run C vai executar o nosso container e aqui, nesse processo 854590, é que a mágica começa a acontecer. Ele tá usando um Anxer e ele tá passando algumas causas muito específicas que vão ser o coração do nosso container. Que é um cloninio NS, cloninio NS, cloninio UTS, cloninio EPC, cloninio PID e cloninio Net. E daí, aqui, a gente já vê num processo abaixo, só que eu entendo um, e a execução do nosso comando e aqui embaixo, ele executando isso novamente, ele executando todos esses clones e aqui, ele já tem um igual a dois. O que significa isso? Aqui, cada siscal dessa representa essa união em espécie diferente. Então, aqui, ele vem pra cá. Então, aqui no BEST, como a gente tá chamando no BEST e a gente tá chamando no AID em um subprocesso, esse processo aqui é um processo que tá sendo executado dentro desse processo, no mesmo processo aqui e dentro dessa execução, ele teve o AID então, isso aqui, virou-se pra dentro desse container que a gente executou como um PID 1 e aqui um PID 2. Agora, vamos entender, já esse passo foi um pouco confuso, mas vamos entender o que são os namespaces, então. O namespace, ele envolve um recurso global do sistema com o PID, Network, Mount, UTS e ele traz isso e ele consegue isolar esse recurso, ele consegue colocar esse recurso dentro de uma caixinha, quem tá de fora na perspectiva do host ele consegue ver tudo que tá acontecendo lá dentro só que quem tá dentro dessa caixinha que a gente imaginou um namespace ela não consegue ver nada pra fora. Então, a gente isolou aquele recurso. Então, a gente pode falar numa forma bem simples e tirando muita coisa, que contenders são basicamente um anuntoado de Linux namespaces. Então, que fazem toda essa magia dos contenders. Vamos ver o que são vamos pegar aquela última linha lá e vamos ver o que são esses namespaces. Então, a gente tem o cgroup namespace, que a syscal, que cria ele, é o clone newCgroup e ele cria um diretório raiz do cgroup. Numa forma uma forma bem simples de falar também, é como se ele fizesse um chr um diretório de cgroup. A gente tem o IPC a flag, que cria ele, é o clone IPC e ele é responsável por comunicação entre processos e compartilhamento de pontos de memória e fila POSIX. A gente tem um network namespace que ele é o clone newNet e ele é responsável por isolar dispositivos de rede stacks de rede, porta e comunicação. A gente tem um mountFS o mount namespace que ele é o clone newNS que ele isola pontos de montagem. A gente tem o PID namespace que a flag dele é o clone newPID e ele isola processos. A gente tem um time, que é o clone newTime que é para ele controlar relógios e a gente tem user namespace que para a gente hoje vai ser onde a gente vai cair um pouco mais a fundo que é o coração do rootless que são isolar a id de processos e poder ter um fake root lá dentro. A gente tem o rootless que a flag para criar ele é o newTS e ele vai isolar para a gente o rootname da máquina. Vamos ver como que funciona cada um desses só que antes vamos ver quem que é um pouco mais a fundo sobre user namespace. O user namespace ele é um dos últimos dos namespaces ele está a partir da versão 3.11 do kernel. Ele consegue isolar a id de processos dentro de um id de processos mapeando eles. Como que é isso? Eu posso ter um usuário fake root eu aqui no exemplo do lado o meu processo no host o meu usuário ele tem o id 1001 só que dentro quando eu uso um user namespace eu consigo ganhar a capacidade de capsa de mim então eu consigo fazer qualquer coisa dentro desse namespace eu também consigo mapear um usuário então eu consigo mapear 1001 na minha perspectiva do host para dentro do container com id 0 então para dentro do container então no que eu estou falando pessoal container eu estou referindo a namespace então quando eu caí lá dentro minha perspectiva de dentro desse container é que eu sou root só que para o meu host eu estou sendo mapeado um fake root lá dentro só que toda a permissão que esse root vai ter é que está atrelado ao meu usuário então eu vou ter um ambiente separado lá dentro com permissões administrativas só que não elas são além das permissões que o meu usuário tem então aqui é um exemplo da gente fazendo isso e como que isso funciona então aqui eu estou na minha máquina eu estou usando, estou com o usuário bonto eu tenho o id 1000 então aqui os grupos que eu estou e aqui eu estou usando o comando enxer que é para a gente criar um namespace eu estou falando que ele vai ser um user namespace e eu estou mapeando o usuário root aqui para dentro eu estou com o usuário 0, então eu sou root está sendo mapeado id 0 e tudo depois os processos numa sequência então aqui é minha perspectiva de dentro do container eu sou id 0 como que funciona esse map dentro do um a gente tem um pacote que eu soub id hoje ele já está vindo padrão em todas as distribuições e ele que vai fazer esses processos dentro, ganharem id ele diz, tenta na perspectiva de dentro do host quanto de dentro do container então aqui o meu usuário root ele tem um id 1000 os processos que vão criar sob o usuário de dentro do namespace eles vão começar com 100, eles tem da renda 100 mil a 65 mil como que é isso? então aqui no meu host o meu id é 1000 dentro do meu namespace ele é 0, então aqui o meu próximo processo ele vai ser 1 dentro então eu tenho 65 mil processos para cada user de namespace que eu criar então vamos aqui para demo, para nossa primeira demonstração dá um play aqui nessa que ela foi gravada então embaixo eu tenho uma perspectiva do meu host em cima eu vou ser, eu vou criar os containers, eu vou utilizar os namespaces então aqui primeiro eu estou demonstrando que eu não tenho permissão, por exemplo para abrir uma porta abaixo então eu estou tentando abrir a porta 80 eu não tenho permissão e eu tentei criar, eu também não tenho permissão também tentei criar um namespace do tipo UTS, eu não tenho essa permissão e eu vou tentar fazer agora a mesma coisa com o namespace do tipo de network, também não tenho permissão então agora eu vou criar um user namespace, só que aqui eu não mapei como usuário root, então ele me jogou com no body e aqui eu já começo a ganhar um tipo de permissão, então vamos ver como que isso é na minha perspectiva do meu host, então aqui dentro eu estou rodando a cor de 65.0234 e vamos ver como que o meu host enxerga isso então dentro do meu host, ele ainda enxerga que é o usuário buntu executando isso, então dentro do namespace eu tenho uma coisa, na perspectiva do meu host eu tenho outra então aqui eu ainda não consegui, dentro de um namespace eu posso abrir outros namespaces e aqui como eu não consegui, eu não tenho então eu também não consigo abrir um namespace do tipo UTS agora o que a gente vai fazer? eu estou criando a mesma coisa, só que agora eu estou mapeando o usuário root, então eu criei um user namespace e agora eu mapei o ad do meu usuário com o ad zero, então na perspectiva do host então na perspectiva do host eu ainda sou o na perspectiva na perspectiva do container eu sou root e vamos ver aqui na perspectiva do host, eu ainda sou o usuário buntu vamos tentar agora um exemplo abrir uma porta abaixo, também não tenho permissão ainda, porque pra isso eu vou precisar utilizar um network namespace e mesma coisa pra gente trocar pra root pra trocar o hostname eu vou precisar a permissão do UTS, desse namespace então agora vamos criar esse novo namespace pra fazer isso só que como eu estou com uma permissão administrativa dentro dentro desse namespace eu vou criar um namespace dentro desse namespace então isso vai ser o coração do rootless eu tenho um namespace, eu poder criar namespaces dentro dele e antes eu, pode ver, eu não tinha permissão pra criar o tipo UTS só que agora eu tenho, porque na perspectiva do meu container eu sou root então aqui vamos fazer o teste eu sou root novamente agora vamos fazer o seguinte, eu vou tentar trocar o hostname da máquina quer dizer, eu também não consegui fazer isso então aqui sucesso, consegui ele me retornou com a CD, então eu consegui trocar essa perspectiva do host então eu tinha um usuário não privilegiado criar um usuário privilegiado e dele eu criei um namespace e eu consegui alterar isso então eu vou tentar fazer um negócio diferente a gente não conseguia abrir a porta 80 então criei um namespace passando a menosnet e eu consegui criar agora abrir a porta 80 só que ainda lá na minha perspectiva do host, ainda é todo o usuário junto então vamos continuar aqui só pra gente entender isso então eu saí do segundo namespace eu não tenho nada, então aqui eu tenho um processo que criou outros processos então o meu processo 1 vai ser um bash agora a gente vai criar um container um pouco mais completo então eu tô passando PID só que aqui ele tá falando que ele tá dando uma errosha alocação de memória e ele tá falando ah, não tem fork, por que? eu não consigo se eu não passar menos-menos fork que é pra eu poder criar sub-processos desse processo então eu preciso passar a flag-menos-fork que vai possibilitar isso acontecer então aqui eu criei, agora eu consigo criar sub-processos, só que ainda aqui eu ainda tô vendo todos os processos do meu host então o que a gente vai fazer agora é criar um namespace do tipo mount, adicionar um namespace do tipo mount e a gente vai mapear ele também no prot aqui a gente só tá vendo que ainda continua tudo na mesma perspectiva do host e agora vou pedir pra ele vamos montar um mount namespace e agora eu tô pedindo pra ele montar o barra prot então agora na perspectiva do meu host o meu pedião eu tô com o usuário root e na perspectiva do meu host agora isso aqui tudo tá sendo executado embaixo do mesmo do mesmo usuário, então são todos sub-processos só que ainda todos eles não tem nenhum privilégio tudo continua com o mesmo privilégio eu consegui abrir a 480 normal e tudo isso com o usuário não privilégio, então aqui a gente trocou o hostname e vamos ver se vai ter algum reflexo no meu host então não teve reflexo nenhum então aqui eu criei novamente e a gente tem um comando no Linux que é lsns que a gente consegue listar esses namespaces então aqui a gente pode ver que a gente tem uma série de namespaces, os padrões a se tender e 1, então a gente tem user namespace a gente tem o mount, o fs, o pid então todos os namespaces que a gente criou e a quantidade de processos que estão embaixo dele, então a gente tem dois pra cada e aqui eu vou criar um novo sub-process, um novo user namespace dentro do meu outro user namespace então aqui a gente pode ver que criou-se um namespace do tipo ts, então o id é diferente de cada namespace e os que eu não passei de forma diferente vão herdar os mesmos namespaces então se a gente comparar ali agora com os outros idis que eu vou mostrar ali agora todos eles são os mesmos exceto o ts que está rodando com um diferente vamos agora para o próximo slide então aqui a gente fez praticamente um container manualmente usando o one share visto tudo isso vamos definir agora o que não é rootless antes de a gente ver o que é rootless permitir acesso ao socket do docker ou adicionar um usuário no grupo do docker, dando user adag no grupo do docker, isso não é rootless você está dando a permissão é a mesma coisa que você dá a permissão de root para um usuário você tem isso até aqui na documentação então se você faz isso você consegue através de um container a pessoa não pode ter acesso a root só de interagir com o docker você não consegue montar o disco inteiro ser um container privilegiado e ter acesso ao host inteiro então vamos falar assim é um tipo de escalação de privilégio com container então é muito perigoso e é uma coisa que acaba sendo comum o pessoal precisa ter acesso a root mas várias pessoas trabalham com docker nessa máquina e é adicionado o usuário de todo mundo no grupo docker a gente executa o container para ele fazer trocando o usuário então com docker run, menos user e passar um ad isso termina o rootless só vai fazer que ele executa e com aquele ad só que o de mundo docker ainda vai continuar sendo executado como root alterar um usuário de dentro do container no nosso processo de build por exemplo fazendo isso vai trocar o nosso usuário só na perspectiva de dentro do container mas o nosso container runtime como o root a mesma coisa a gente trocar isso dentro do security context do Kubernetes vai dar a mesma coisa a gente utilizar o docker no modo user ns e ele fazer o remap do ns então ele vai criar todos esses subnamespaces e criar tudo lá dentro criando uma piano zero só que o que acontece isso é a mesma coisa para o podman pessoal agora rapidinho é só um alerta de slide branco então como está tudo escuro vai clarear um pouco como funciona na perspectiva do host e do container se eu não estou utilizando o name space o meu id zero está sendo mapeado com o id do root então continua a mesma coisa e aqui se eu mapeo de um container ele vai mapear direto o meu id do host se eu estou rodando o docker utilizando o recurso de user ns meta eu vou passar para ele o meu id zero que o docker vai rodar ele ainda vai continuar sendo zero do meu host só que agora o zero do meu container vai ser mapeado a um id alto que a gente vai criar esse mapping então só que eu ainda tenho o meu demon rodando com root só que aqui entra o rootless o que que é o rootless? o meu id zero está sendo mapeado a um usuário sem privilégio nenhum e tudo vai ser criado embaixo desse mapping em todos os usuários mesmo que eu queira um usuário root ele está sendo mapeado no usuário sem privilégio algum então então agora vamos definir o que que é o rootless o rootless é a capacidade de criar um container executar a gerenciar também isso também se aplica aos arbitradores de container que a gente consegue executar essa ferramenta sem nenhum privilégio administrativo e quando a gente fala de nenhum privilégio administrativo isso também aborda instalar o pacote a gente não precisa então eu consegui baixar tudo executar com o meu usuário e não tenho nenhum tipo de problema e isso também eu não preciso ter sudo eu não preciso ter nada e se aplica a qualquer tipo de container então eu tenho um container na mão eu uso a docker poderman cryo então é uma técnica no geral de executar qualquer container sem nenhum privilégio administrativo com o usuário comum então por que a gente usa o rootless o rootless por mais que todos os vamos falar assim vamos pegar como base a palestra do magnum hoje pra quem viu falando sobre vulnerabilidade no projeto e também esse critim vulnerabilidade um processo por exemplo como os próprios runc cooblet docker container g por mais que esse software sejam pensados 100% em segurância desenvolvido com a melhor com o maior cuidado de atenção na segurança sempre a vulnerabilidade pode acontecer no passado a gente viu uma quantidade muito grande vulnerabilidade do gdn projetos e por que isso é perigoso quando você tem qualquer um desses componentes explorado simplesmente uma pessoa tem o root da máquina então isso cai nesse nosso terceiro ponto aqui que é de um milhão maior superfície de ataque quando a gente fala de minting containers que é qualquer coisa desse ambiente for explorado por exemplo se a gente conseguir explorar o runc e um cooblet até mesmo alguma falha no docker eu consegui escapar desse container de alguma forma utilizando alguma vulnerabilidade até mesmo com uma configuração isso é muito importante e rumano sempre vai acontecer não importa por mais que a gente tenha gtkeeper cuidando a gente tenha secret chain e rumano sempre pode acontecer no passado a gente viu muito exemplo disso com muito desastre que aconteceu então sempre pode acontecer por maior que seja o ambiente mais sofisticado e rumano sempre pode acontecer esses projetos também tem vulnerabilidades a quantidade de recursos por exemplo só que a gente do docker é exposto pra internet cooblets tem a autenticação com bpi sem a autenticação tudo isso pode cometer um embrinte de uma forma muito grande só que se a gente está usando a técnica de rootless se qualquer desses componentes flores explorados sair do meu container eu ainda estou com usuário sem privilégio então por mais que eu tenha uma quebra de segurança ele ainda está dentro isolado separadinho sem nenhum privilégio na máquina isso por exemplo vai impedir por exemplo de uma coisa ser explorada e ser instalada no rootkit onde não vai conseguir ser detectado só que isso daqui nem tudo é só alegria quando a gente fala de rootless hoje o maior ponto é a complexibilidade então ele é uma coisa muito complexa para a gente manter, criar, organizar então por enquanto muita imagem das codes não suporta a gente vai precisar de alguns recursos muito específicos a gente não vai conseguir mapear portas baixas até dar mas já foge do conceito porque eu precisaria dar uma permissão administrativa para aquele usuário conseguir abrir portas baixas eu vou precisar dos ser grupos v2 porque ele habilita o delegation a gente vai ver um pouco a frente mas é a possibilidade de um usuário não administrativo criar os grupos de ser group todas as nodes ports que a gente criou agora no caso de um contexto do Kubernetes elas vão ser separadas para dentro daquele name space, elas só vão assistir ali dentro por enquanto ele não suporta a API Armor a maioria de volume não local por exemplo como NFS e SCSI não funcionam a gente precisa ter um kernel maior do que 4.18 para utilizar Overlay 2 a gente vai precisar de um kernel maior de 5.1 ou os kernels do mundo para utilizar Overlay FS o Flux Overlay FS a gente precisa de um kernel 4.8 maior por enquanto a gente não tem nenhuma ferramenta de bootstrapping então é somente Hardware e alguns plugins como o CNI também não funcionam então por enquanto que essa vídeo que funciona são vídeos locais e utilizando a Flannel e o Calico no modo VXLAN então agora vamos só para uma pequena demonstração de como que funciona o rootless um pouco na prática então aqui eu estou instalando rootless, então esse processo de instalação por exemplo do Docker é extremamente simples, eu estou com o usuário de um mesmo que a gente estava trabalhando anteriormente eu estou dando um kernel para pegar o script dele e estou jogando a saída dele para um script, para um shell e aqui ele vai startar ele configurou para mim e ele pede só que eu exporte dois variáveis de ambiente que é o path do bind dele e o socket do Docker então vamos fazer isso exportei aqui, então está instalado então não precisei rodar nenhum apk nenhum apt aqui eu já tenho um Docker rodando ele já me respondeu ele já me fala do Olin por causa dos C Groups V2 agora o que a gente vai fazer? vamos criar um container para ver como funciona isso na perspectiva do host na perspectiva do usuário que está rodando isso então aqui eu vou criar um container simples então eu vou dar um Docker 1 eu vou jogar o processo para o backup eu vou jogar ele com Dino eu vou usar o Slip novamente para a gente ver estou baixando a imagem, sem nenhum problema para baixar essa imagem agora o que eu vou fazer? vamos ver como está a visão do host lá dentro com Docker PS vou dar um PS e procurar pelo processo do Slip primeiro só vamos ver o processo do Docker então pode ver que todos os processos do Docker, do Docker Team do container G, de todos eles eles estão sendo executados com o usuário do Ubuntu, então eu não tenho nada de root rodando vamos continuar tudo com o usuário Ubuntu vou procurar com o Slip tudo rodando com o usuário Ubuntu sem problema nenhum agora embaixo estou com uma perspectiva do host na máquina de baixo é a mesma máquina estou com uma perspectiva e tenho o Docker normal vamos ver qual é a principal diferença entre isso Docker PS eu estou rodando dentro um rootless container está tudo dentro do meu usuário Ubuntu todas as permissões embaixo é um Docker normal vou rodar um Slip também só passa aqui para a gente não perder muito tempo agora vamos ver grepando isso, procurando por Slip o meu processo 1 ele está sendo executado com o usuário Ubuntu sem problema com o Slip 100 e o Slip 200 eu só queria um container normal e ele está sendo criado e o dono desse processo é o root na minha perspectiva do host isso que é o perigoso que é o que chama a atenção e que motivou o projeto para fazer isso então é isso dessa demo agora que vem o nosso próximo passo agora na release 1.22 do Kublet ele ganhou o suporte oficial alpha a executar os componentes de Nock que é o Kublet, CRI, OCA e SNI News and Name Space isso ganhou através da proposta KIP233 e isso tornou isso possível então o que foi que essa proposta fez e alterou elas foram dois patches que foram feitos um foi um patch no Kublet que foi para ele ignorar alguns erros que antes dava um problema nele e como ele não tinha acesso suficiente para fazer para ver isso então é que o processo não parasse tudo isso através de uma função username space a gente vai ver isso um pouco para frente e uma alteração no Kub Proxy também para que ele possa suportar tudo isso quem já está usando o rootless rootless ele já foi adotado por alguns projetos antes mesmo de se tornar oficial que é no caso quando a gente roda o Kubernetes dentro de um container então que é no caso o exemplo do kind o kind falando dos primeiros já adotar o suporte ao rootless antes era feito um patch agora já não é mais o binário original a gente tem nesse mesmo cenário o minikube e agora os que são diretamente no host a gente tem o K3S também hoje já possui o modo rootless e a gente tem o usernet o usernet ele é uma distribuição Kubernetes que foi baseada ela foi feita para a prova de conceito para mostrar que isso funcionava e embasar aquela proposta então ali tem todos os exemplos de como funciona de como executa ele tem uns rápidos setup só que ele é uma prova de conceito e agora vamos para a nossa terceira demonstração que é o the hardware então aqui a gente tem três links que a gente se baseou para fazer isso o primeiro é a task que tem lá na documentação do Kubernetes quando a gente fala do Kublet em username space e aqui a gente tem usernet de hardware aqui são mais dicas do que a gente precisa fazer para isso funcionar lá a gente por enquanto a gente não tem o passo a passo mas a gente tem uma noção de tudo o que precisa ser feito para isso funcionar a gente usou com base para fazer toda a configuração ou seja de tudo a gente usou o Kubernetes de hardware eu gosto muito desse projeto do hardware que é o seguinte hoje quando a gente fala dos processos do control plane e os componentes de de node do Kubernetes tem um mistério muito grande só que pessoal, eles só são binários que precisam ser executados para fazer uma função então eles são um pacote executável e tudo bem, então o BPI é um pacote o Kublet é outro então eles só precisam ser executados e a gente mostra como fazer isso manual e ele tira um pouco desse área de mistério que existe por ter algumas coisas e a gente também se baseou nessa prova de conceito executando e pegando algumas coisas para fazer isso realmente funcionar então no macro o que a gente precisa a gente precisa criar um namespace rodar os programas lá dentro e a gente precisa criar um socket para fazer que isso exista que a gente consiga acessar esse cluster por fora do namespace eu quero acessar ele por fora da minha perspectiva de host então o que eu vou usar para criar o namespace eu vou usar uma tool que chama rootless kit ele possui um vamos falar assim, ele é um canivético quando a gente fala de rootless então ele tem uma série de opções para facilitar a minha vida quando a gente fala de rootless containers então o podman no modo rootless usa ele o docker também então ele já é muito usado nesse universo a sr a gente vai usar o container G para network a gente vai usar o slip for net in s o slip ele é uma técnica que traduz pacotes internet para syscals não privilegiadas e a gente vai usar o file system a gente vai usar o fuzil overlay fs o fuzil no overlay fs ele significa file system in usernamespace então vamos aqui para a prática pessoal eu deixei gravado porque é muito complicado então se a gente precisar a gente tem um aqui vou compartilhar o meu terminal pessoal, está dando para ver bem a fonte está ok beleza então lembrando daqueles passos como eu preciso de um processo para eu se estender, o que eu vou fazer agora para fazer funcionar eu preciso que o se estender execute para eu ter permissão de criar cgroups então aqui eu criei o myonich no local no syscals então aqui ele vai executar a minha linha do rootless kit então eu estou falando qual que é o meu direitório, onde estava os binário do Kubernetes, qual network ele vai usar qual que é o MT ou dessa interface o que é o sendbox quais são os namespaces, o que ele vai copiar para criar o overlay fs e aqui eu estou falando que ele vai ser o delegate, o delegate é eu vou possibilitar que ele que esse meu processo consiga criar sem nenhum privilégio, tipo cgroup então agora eu vou dar um start nesse meu processo e aqui ele vai criar o namespace para a gente, então lsns ele me entregou aqui o processo, então eu tenho user namespace eu tenho mount namespace um pid namespace e uts agora eu vou pegar esse meu id principal e eu vou começar a executar os meus pacotes para deixar um pouco a demo um pouco mais rápido eles já foram baixados então eu só baixei o pacote lá do git, normal não tem nada diferente então o que eu vou fazer aqui então a primeira coisa, eu estou no meu processo antes disso eu só deixo então aqui eu tenho um show script que ele starta o container de para a gente faz alguns ajustes ele exporta um path para dentro e aqui ele tem esse namespace então ele está mapeando os binários lá dentro eu estou apagando alguns diretórios copiando o meu arquivo de configuração da MSNi para lá e montando um diretório eu estou fazendo um mount dos meus diretórios que eu preciso para tudo isso rodar e eu estou girando um arquivo temporário com as configurações do container de, do kubiproxy e do kublet tudo isso aqui foi a configuração do meu processo principal que é o processo do container de então agora para funcionar eu preciso subir o meu overlay fs e eu vou jogar ele para a background ok agora eu vou subir o meu etcd só explicando o comando esse ns enter é um executável que ele permite que a gente execute ou ente dentro de um namespace então eu passo aqui para ele que ele vai ser um user namespace que ele vai ser um mount namespace então qualquer um diretório raiz e o comando que eu quero executar então aqui é tudo o que eu preciso para subir o etcd então estou subindo o etcd vou jogar ele para a background agora a mesma coisa eu vou executar o kubipi manualmente também a mesma coisa, toda a mesma lógica passando todos os mesmos processos então tudo está sendo criado sobre esse processo que é o processo que criou que é o processo que segura os mesmos processos então eu joguei o meu etcd também, joguei ele para a background continuando subindo os processos do comando então a gente precisa subir o kubiproxy que era um componente que não funcionava até 22 vou subir também o scheduler jogando para a background para ficar mais limpo para a gente também vou subir o controller todo jogando ele para a background e agora eu vou subir o meu kubi então joguei ele para a background vou entrar aqui dentro desse diretor que está sendo criado para esse namespace só para a gente ver o que está executando lá dentro então se eu dar um ps na perspectiva do namespace eu só tenho esses processos que são os meus nodes componentes vou sair aqui do namespace agora o que eu vou fazer eu vou abrir um socket e eu vou mapear a porta 6443 para o meu processo então eu vou abrir do meu host na perspectiva do meu host para o meu container agora eu vou pegar o meu kubi config eu vou mapear para o meu usuário até acesso e agora vou dar um kubicetl get nodes e a gente tem um node read vou dar um kubicetl get pods não tem nada então vou dar um kubicetl run index e mais index vou dar um get pod de novo vamos esperar ele criar o container para a gente pode demorar um pouquinho porque até a internet está um pouco ruim mas enquanto isso o que a gente vai fazer vamos criar um node pod para ele tem um kubicetl expose index tranquilo, vamos ver se aqui ele já criou o meu pod aqui eu vou mostrar no outro demo porque a internet não está dos melhores então para baixar eu estou numa vm vai ser um pouquinho complicado então só deixa eu trocar para dar outra demo então aqui eu gravei um processo um pouco antes de entrar aqui na cal então já estou pulando para o final onde a gente cria o processo do enginex e faz ele funcionar enquanto isso deixa eu só ver caso baixa imagem aqui rapidinho só vamos ver se vai então a internet não está dos melhores para baixar mas aqui a gente tem um kubicetl totalmente funcional para isso deixa eu só tentar aqui novamente deixa eu sair do voltar o slide para ver se ele vai carregar para a gente ele não quer carregar o vídeo para a gente mas ali eu consigo criar, não resumo, eu consigo criar o eu consigo criar um contender e eu consigo acessar ele via network tranquilo, vamos ver se agora vai vamos ver só deixa eu diminuir um pouco a qualidade aqui pessoal eu acho que eu não consegui mostrar ele executando para você ah foi então aqui tem os meus pods creio enginex, expus a porta dele expus a porta dele eu estou vendo qual é a porta que eu estou executando então é a porta 80 e eu vou expor isso na perspectiva do hosting então não é acessado do hosting na porta 80 e aqui deixa eu só pegar a linha certinho para vocês verem eu vou criar um socket que vai mapear essa porta igual eu fiz então deixa eu só pegar aqui aqui não pego mas aqui eu consigo acessar esse recurso tranquilo funcionando e a gente pode ver aqui todos os processos estão embaixo do meu usuário então eu estou rodando um Kubernetes totalmente funcional tudo embaixo do meu usuário é nada com permissão de root então aqui é um pouco da perspectiva de todos os processos que foram criados tudo embaixo do meu usuário tudo tranquilo para o futuro do projeto tem uma ferramenta como Kubernetes para fazer bootstrap, diminuir a com menor complexibilidade e fazer o SCSI NFS, por exemplo, funcionário eu acho que eu estarei uns minutinhos do tempo alguém tem alguma dúvida se quiser mandar no chat aqui são as referências do projeto de tudo que eu usei então o root o containers.rs é onde está tudo do conceito, como funciona tudo, a prova de conceito que eu uso o usernet, o manual do kernel do kernel linux a documentação sobre o processo um livro que ajudou muito foi o container security da Liz Rice e algumas palestras da Kubicom e do canal da Sensei, que é o rootless containers from scratch da Liz Rice container de com atiro suda que é uma das pessoas mais ativas sobre o rootless e outra palestra da Liz Rice que é o one share of the name space for the rootless container é isso pessoal muito obrigado Mauro estou muito feliz de estar aqui com vocês espero que eu tenha conseguido passar um pouco nervoso mas aí também as redes sociais, meu git para todos quem quiser e é isso pessoal quero ver umas perguntas aí você é a última palestra mesmo então manda a gente se tiver tem aí, vamos ver tudo bem Carlos, os caras já são quase duas da manhã lá na Alemanha eu tenho três perguntas a gente fecha nessas três então pode ser João? Beleza o Hugo perguntou se você sabe se o Bottle Rocket OS da AWS que é um Linux escrito em Rust é rootless pois ele tem um conceito de users que precisa de um container administrador para configurar o sistema eu me perdi a idade cara eu já ouvi falar sobre ela mas assim a funda não consigo afirmar preciso ver mais uma teoria umas chamadas mas nada muito a fundo beleza o Bele pergunta se o OpenShift trabalha como rootless ou alguma outra ferramenta que é a Cloud eu não vi nada por enquanto sobre o OpenShift por enquanto, eu sei que o Podman tem suporte mas do OpenShift não tenho certeza a última pergunta do Jorge se o Coby Proxy no Netname Space se conseguir fazer as treta no IPT ou tem que usar o IPProxy em UserBold cara eu acho que ele vai ele usa em UserMold ele consegue fazer tudo eu não tive problema mas assim no detalhe eu precisava ver para falar depois agora criou a imagem graças a minha internet minhas VN demorou só um pouco para baixar a imagem eu vou, deixa eu ver, acho que tem mais alguma coisa que você esteja vendo e para Nato estando aqui nos chat você não achei nenhuma outra pergunta beleza meu cabelo de Krusty já foi para o saco já já quase não tem cabelo acho que é isso João, obrigadão obrigada mesmo aí a palestra foi sensacional para variar uma lição de Kelly o Linux e outras coisas aí eu acho que a gente agora vai partir para o encerramento antes antes até a gente partir para o encerramento só lembrar pessoal que quem ganhou os ingressos os ingressos são os vouchers para CKA a gente postou um e-mail está pinado lá no chat eu vou depois pegar com a organização da cncf também e postar no twitter vou pedir para o João, vou pedir para o Jefferson que também é alguém que tem mais abrangência no twitter provavelmente a pessoa que ganhou vai ver o nome dela lá mas não deixem de ver esse voucher depois e resgatar ele porque é muito bacana a oportunidade inclusive de tirar CKA e é uma certificação que o mercado tem vou falar que tem solicitado mas que brilha o olho do recrutador do entrevistador técnico aí quando você tem a CKA o Jefferson tem os treinamentos da CKA e os tipos tem os treinamentos da CKA você não me engana a gear up que é a nossa participadora também tem alguns treinamentos de cabinets que vai para CKA então eu acho que eu acho que recurso não falta aí para tirar a certificação e aí é só aquela questão de sentar o dedo ali nos estudos e aí eu diria que a própria certificação ela tem um retrai se você não passa na primeira você pode tentar fazer uma segunda depois de um tempo ela tem um retake lá, é isso aí então bora para esse herramienta aqui e para nato vamos lá então obrigado obrigado