Pavel Selivanov, arquitecto de solucións de Southbridge e profesor de Slurm, fixo unha presentación en DevOpsConf 2019. Esta charla forma parte dun dos temas do curso en profundidade sobre Kubernetes "Slurm Mega".
terá lugar en Moscova do 18 ao 20 de novembro.
- Moscova, 22-24 de novembro.
sempre dispoñible.
Debaixo do corte hai unha transcrición do informe.
Boas tardes, compañeiros e compañeiras e os que os simpatizades. Hoxe falarei de seguridade.
Vexo que hoxe hai moitos gardas de seguridade no salón. Pídoche desculpas por adiantado se uso termos do mundo da seguridade non exactamente como é habitual para ti.
Aconteceu que hai uns seis meses atopeime cun clúster público de Kubernetes. Público significa que hai un enésimo número de espazos de nomes; nestes espazos de nomes hai usuarios illados no seu espazo de nomes. Todos estes usuarios pertencen a distintas empresas. Ben, supuse que este clúster debería usarse como CDN. É dicir, danche un clúster, danche un usuario alí, vas alí ao teu espazo de nomes, desprega as túas frontes.
A miña empresa anterior intentou vender tal servizo. E pedíronme que fixera o clúster para ver se esta solución era axeitada ou non.
Cheguei a este grupo. Déronme dereitos limitados, espazo de nomes limitado. Os rapaces de alí entendían o que era a seguridade. Leron sobre o control de acceso baseado en roles (RBAC) en Kubernetes e torceronno para que non puidese lanzar pods por separado dos despregamentos. Non recordo o problema que intentaba resolver lanzando un pod sen implementación, pero realmente quería lanzar só un pod. Para ter boa sorte, decidín ver que dereitos teño no clúster, que podo facer, que non podo facer e que putaron alí. Ao mesmo tempo, vouche dicir o que configuraron incorrectamente en RBAC.
Aconteceu que en dous minutos recibín un administrador do seu clúster, mirei todos os espazos de nomes veciños, vin alí as frontes de produción en marcha das empresas que xa compraran e implantaran o servizo. Apenas puiden impedirme de ir á fronte de alguén e de poñer algún insulto na páxina principal.
Vouche contar con exemplos como fixen isto e como protexerte disto.
Pero antes, déixeme presentarme. Chámome Pavel Selivanov. Son arquitecto en Southbridge. Entendo Kubernetes, DevOps e todo tipo de cousas extravagantes. Os enxeñeiros de Southbridge e eu estamos construíndo todo isto, e estou a asesorar.
Ademais das nosas actividades principais, lanzamos recentemente proxectos chamados Slurms. Estamos tentando achegar un pouco a nosa capacidade de traballar con Kubernetes ás masas, para ensinar a outras persoas a traballar tamén con K8.
De que vou falar hoxe? O tema do informe é obvio: sobre a seguridade do clúster de Kubernetes. Pero quero dicir de inmediato que este tema é moi grande e, polo tanto, quero aclarar inmediatamente o que definitivamente non vou falar. Non vou falar de termos maniáticos que xa se usaron cen veces en Internet. Todo tipo de RBAC e certificados.
Falarei do que me doe a min e aos meus compañeiros sobre a seguridade nun clúster de Kubernetes. Vemos estes problemas tanto entre os provedores que proporcionan clústeres de Kubernetes como entre os clientes que veñen a nós. E mesmo de clientes que veñen a nós doutras empresas de consultoría administrativa. É dicir, a escala da traxedia é en realidade moi grande.
Hai literalmente tres puntos dos que vou falar hoxe:
- Dereitos de usuario vs dereitos de pod. Os dereitos de usuario e os dereitos de pod non son o mesmo.
- Recollida de información sobre o clúster. Vou amosar que pode recoller toda a información que precisa dun clúster sen ter dereitos especiais neste clúster.
- Ataque DoS ao clúster. Se non podemos recoller información, poderemos poñer un clúster en calquera caso. Falarei dos ataques DoS aos elementos de control do clúster.
Outra cousa xeral que vou mencionar é o que probei todo isto, sobre o que definitivamente podo dicir que todo funciona.
Tomamos como base a instalación dun clúster de Kubernetes mediante Kubespray. Se alguén non o sabe, este é un conxunto de papeis para Ansible. Usámolo constantemente no noso traballo. O bo é que podes enrolalo en calquera lugar: podes enrolarlo en anacos de ferro ou nunha nube nalgún lugar. Un método de instalación funciona en principio para todo.
Neste clúster terei Kubernetes v1.14.5. Todo o clúster de Cube, que consideraremos, está dividido en espazos de nomes, cada espazo de nomes pertence a un equipo separado e os membros deste equipo teñen acceso a cada espazo de nomes. Non poden ir a diferentes espazos de nomes, só aos seus. Pero hai unha determinada conta de administrador que ten dereitos sobre todo o clúster.
Prometín que o primeiro que faremos será obter dereitos de administrador do clúster. Necesitamos un pod especialmente preparado que rompa o clúster de Kubernetes. Todo o que temos que facer é aplicalo ao clúster de Kubernetes.
kubectl apply -f pod.yamlEste pod chegará a un dos mestres do clúster de Kubernetes. E despois disto, o clúster devolverános un ficheiro chamado admin.conf. En Cube, este ficheiro almacena todos os certificados de administrador e, ao mesmo tempo, configura a API do clúster. Así de fácil é conseguir acceso de administrador a, creo, o 98% dos clústeres de Kubernetes.
Repito, este pod foi feito por un desenvolvedor do teu clúster que ten acceso para implementar as súas propostas nun pequeno espazo de nomes, todo está protexido por RBAC. Non tiña dereitos. Pero, con todo, o certificado foi devolto.
E agora sobre unha vaina especialmente preparada. Executámolo en calquera imaxe. Tomemos debian:jessie como exemplo.
Temos isto:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Que é a tolerancia? Os mestres nun clúster de Kubernetes adoitan estar marcados con algo chamado contaminación. E a esencia desta "infección" é que di que as vainas non se poden asignar aos nodos mestres. Pero ninguén se molesta en indicar en ningunha vaina que é tolerante á "infección". A sección Toleración só di que se algún nodo ten NoSchedule, entón o noso nodo é tolerante a tal infección e non hai problemas.
Ademais, dicimos que o noso baixo non só é tolerante, senón que tamén quere dirixirse específicamente ao mestre. Porque os mestres teñen o máis delicioso que necesitamos: todos os certificados. Polo tanto, dicimos nodeSelector - e temos unha etiqueta estándar nos mestres, que permite seleccionar entre todos os nodos do clúster exactamente aqueles que son mestres.
Con estas dúas seccións chegará definitivamente ao mestre. E permitiralle vivir alí.
Pero só vir ao mestre non nos abonda. Isto non nos dará nada. Entón, a continuación temos estas dúas cousas:
hostNetwork: true
hostPID: true Especificamos que o noso pod, que lanzamos, vivirá no espazo de nomes do núcleo, no espazo de nomes da rede e no espazo de nomes PID. Unha vez que o pod se lance no mestre, poderá ver todas as interfaces reais e en directo deste nodo, escoitar todo o tráfico e ver o PID de todos os procesos.
Despois é cuestión de pequenas cousas. Colle etcd e le o que queiras.
O máis interesante é esta función de Kubernetes, que está presente alí por defecto.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host E a súa esencia é que podemos dicir no pod que lanzamos, aínda sen dereitos sobre este clúster, que queremos crear un volume de tipo hostPath. Isto significa tomar o camiño do host no que lanzaremos e tomalo como volume. E entón chamámoslle nome: host. Montamos todo este hostPath dentro do pod. Neste exemplo, ao directorio /host.
Volvereino a repetir. Dixémoslle ao pod que chegase ao mestre, que fixera alí o hostNetwork e hostPID e que montara toda a raíz do mestre dentro deste pod.
Entendes que en Debian temos bash en execución, e este bash execútase baixo root. É dicir, acabamos de recibir root no mestre, sen ter ningún dereito no clúster de Kubernetes.
A continuación, toda a tarefa é ir ao subdirectorio /host /etc/kubernetes/pki, se non me equivoco, recoller alí todos os certificados mestres do clúster e, en consecuencia, converterse no administrador do clúster.
Se o miras deste xeito, estes son algúns dos dereitos máis perigosos dos pods, independentemente dos dereitos que teña o usuario:
Se teño dereitos para executar un pod nalgún espazo de nomes do clúster, entón este pod ten estes dereitos por defecto. Podo executar pods privilexiados, e estes son xeralmente todos os dereitos, practicamente root no nodo.
O meu favorito é o usuario root. E Kubernetes ten esta opción Executar como non root. Este é un tipo de protección contra un hacker. Sabes o que é o "virus moldavo"? Se de súpeto es un pirata informático e chega ao meu clúster de Kubernetes, entón nós, malos administradores, preguntámoslle: "Indique nos seus pods con que pirateará o meu clúster, executado como non root. En caso contrario, ocorrerá que executas o proceso no teu pod baixo root, e será moi fácil para ti piratearme. Protéxete de ti mesmo".
O volume da ruta do host é, na miña opinión, a forma máis rápida de obter o resultado desexado dun clúster de Kubernetes.
Pero que facer con todo isto?
O pensamento que debería chegar a calquera administrador normal que se atope con Kubernetes é: "Si, xa cho dixen, Kubernetes non funciona. Hai buratos nel. E todo o Cubo é unha merda". De feito, existe a documentación, e se miras alí, hai unha sección .
Este é un obxecto yaml -podemos crealo no clúster de Kubernetes- que controla os aspectos de seguridade especificamente na descrición dos pods. É dicir, de feito, controla os dereitos para usar calquera hostNetwork, hostPID, certos tipos de volume que están nos pods ao inicio. Coa axuda da Política de seguridade do pod, pódese describir todo isto.
O máis interesante da Política de seguranza do Pod é que no clúster de Kubernetes, todos os instaladores de PSP non só non se describen de ningún xeito, senón que simplemente están desactivados por defecto. A política de seguranza do pod está habilitada mediante o complemento de admisión.
Está ben, imos implementar a Política de seguranza de pods no clúster, digamos que temos algúns pods de servizo no espazo de nomes, aos que só teñen acceso os administradores. Digamos que, en todos os demais casos, os pods teñen dereitos limitados. Porque o máis probable é que os desenvolvedores non teñan que executar pods con privilexios no teu clúster.
E todo parece estar ben con nós. E o noso clúster de Kubernetes non pode ser pirateado en dous minutos.
Hai un problema. O máis probable é que se tes un clúster de Kubernetes, a supervisión estea instalada no teu clúster. Incluso iría a predicir que se o seu clúster ten monitorización, chamarase Prometheus.
O que estou a piques de dicirche será válido tanto para o operador Prometheus como para Prometheus entregado na súa forma pura. A pregunta é que se non podo conseguir un administrador no clúster tan rápido, isto significa que teño que buscar máis. E podo buscar coa axuda do teu seguimento.
Probablemente todos lean os mesmos artigos sobre Habré, e o seguimento está situado no espazo de nomes de seguimento. O gráfico de timón chámase aproximadamente igual para todos. Supoño que se instalas helm stable/prometheus, terás aproximadamente os mesmos nomes. E o máis probable é que nin sequera teña que adiviñar o nome DNS do teu clúster. Porque é estándar.
A continuación temos uns dev ns determinados, nos que pode executar un determinado pod. E entón desde este pod é moi sinxelo facer algo así:
$ curl http://prometheus-kube-state-metrics.monitoring prometheus-kube-state-metrics é un dos exportadores de Prometheus que recolle métricas da propia API de Kubernetes. Hai moitos datos alí, o que se está a executar no teu clúster, o que é, que problemas tes con el.
Como exemplo sinxelo:
kube_pod_container_info{namespace=“kube-system”,pod=”kube-apiserver-k8s- 1″,container=”kube-apiserver”,image=
"gcr.io/google-containers/kube-apiserver:v1.14.5"
,image_id=»docker-pullable://gcr.io/google-containers/kube- apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker://7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1
Ao facer unha simple solicitude de curl desde un pod sen privilexios, podes obter a seguinte información. Se non sabes que versión de Kubernetes estás a executar, dirá facilmente.
E o máis interesante é que ademais de acceder a kube-state-metrics, podes acceder directamente ao propio Prometheus con igual facilidade. Podes recoller métricas desde alí. Incluso podes construír métricas a partir de aí. Incluso teoricamente, podes construír esa consulta desde un clúster en Prometheus, que simplemente a desactivará. E o teu seguimento deixará de funcionar desde o clúster por completo.
E aquí xorde a pregunta de se algún monitoreo externo supervisa o teu monitor. Acabo de ter a oportunidade de operar nun clúster de Kubernetes sen ningunha consecuencia para min. Nin sequera saberás que estou operando alí, xa que xa non hai vixilancia.
Do mesmo xeito que coa PSP, parece que o problema é que todas estas tecnoloxías sofisticadas (Kubernetes, Prometheus) simplemente non funcionan e están cheas de buratos. En realidade non.
Hai tal cousa - .
Se es un administrador normal, o máis probable é que saibas sobre a Política de rede que este é só outro yaml, do que xa hai moitos no clúster. E algunhas políticas de rede definitivamente non son necesarias. E aínda que leas o que é a Política de rede, que é un firewall yaml de Kubernetes, permíteche limitar os dereitos de acceso entre espazos de nomes, entre pods, entón certamente decidiches que o firewall en formato yaml en Kubernetes está baseado nas próximas abstraccións. ... Non, non. Isto definitivamente non é necesario.
Aínda que non lle dixeses aos teus especialistas en seguridade que usando o teu Kubernetes podes construír un firewall moi sinxelo e sinxelo, e un moi granular. Se aínda non o saben e non che molestan: "Ben, dáme, dáme..." En calquera caso, necesitas a Política de rede para bloquear o acceso a algúns lugares de servizo que se poden extraer do teu clúster. sen ningunha autorización.
Como no exemplo que dei, podes extraer as métricas de estado de Kube desde calquera espazo de nomes do clúster de Kubernetes sen ter ningún dereito para facelo. As políticas de rede pecharon o acceso desde todos os demais espazos de nomes ao espazo de nomes de monitorización e xa está: sen acceso, sen problemas. En todos os gráficos que existen, tanto o Prometheus estándar como o Prometheus que está no operador, simplemente hai unha opción nos valores de timón para activar simplemente as políticas de rede para eles. Só tes que acendelo e funcionarán.
Hai realmente un problema aquí. Sendo un administrador barbudo normal, probablemente decidiches que as políticas de rede non son necesarias. E despois de ler todo tipo de artigos sobre recursos como Habr, decidiches que a franela, especialmente co modo de pasarela de host, é o mellor que podes escoller.
¿Que facer?
Podes tentar volver implementar a solución de rede que tes no teu clúster de Kubernetes, tenta substituíla por outra máis funcional. Para o mesmo Calico, por exemplo. Pero quero dicir de inmediato que a tarefa de cambiar a solución de rede nun clúster de traballo de Kubernetes non é nada trivial. Resolveino dúas veces (as dúas veces, con todo, teoricamente), pero ata mostramos como facelo en Slurms. Para os nosos estudantes, mostrámoslle como cambiar a solución de rede nun clúster de Kubernetes. En principio, podes intentar asegurarte de que non haxa tempo de inactividade no clúster de produción. Pero probablemente non teñas éxito.
E o problema resólvese de xeito moi sinxelo. Hai certificados no clúster e sabes que os seus certificados caducarán nun ano. Ben, e normalmente é unha solución normal con certificados no clúster: por que nos preocupa, levantaremos un novo clúster preto, deixaremos que o antigo se podre e volveremos implementar todo. É certo, cando se podre, teremos que sentar un día, pero aquí tes un novo grupo.
Cando creas un novo racimo, introduce ao mesmo tempo Calico en lugar de franela.
Que facer se os seus certificados se emiten durante cen anos e non vai volver implantar o clúster? Hai algo como Kube-RBAC-Proxy. Este é un desenvolvemento moi interesante, que permítelle incorporarse como un contenedor sidecar en calquera pod do clúster de Kubernetes. E realmente engade autorización a este pod a través do RBAC do propio Kubernetes.
Hai un problema. Anteriormente, esta solución Kube-RBAC-Proxy integrouse no Prometheus do operador. Pero entón foise. Agora, as versións modernas confían no feito de que tes unha política de rede e pechaa usándoa. E polo tanto teremos que reescribir un pouco o gráfico. De feito, se vai , hai exemplos de como usar isto como sidecars, e os gráficos terán que ser reescritos mínimamente.
Hai un pequeno problema máis. Prometheus non é o único que entrega as súas métricas a calquera. Todos os nosos compoñentes do clúster de Kubernetes tamén poden devolver as súas propias métricas.
Pero como xa dixen, se non podes acceder ao clúster e recoller información, polo menos podes facer algún dano.
Entón, mostrarei rapidamente dúas formas en que se pode arruinar un clúster de Kubernetes.
Rirás cando che diga isto, son dous casos da vida real.
Método un. Esgotamento dos recursos.
Imos lanzar outro pod especial. Terá unha sección coma esta.
resources:
requests:
cpu: 4
memory: 4Gi Como sabes, solicitudes é a cantidade de CPU e memoria que se reserva no host para pods específicos con solicitudes. Se temos un host de catro núcleos nun clúster de Kubernetes e catro módulos de CPU chegan alí con solicitudes, significa que non poderán chegar máis pods con solicitudes a este host.
Se executo un pod así, executarei o comando:
$ kubectl scale special-pod --replicas=...Entón, ninguén máis poderá implementarse no clúster de Kubernetes. Porque todos os nodos quedarán sen solicitudes. E así deixarei o teu clúster de Kubernetes. Se o fago á noite, podo deter os despregamentos durante bastante tempo.
Se miramos de novo a documentación de Kubernetes, veremos isto chamado Rango límite. Establece recursos para obxectos de clúster. Podes escribir un obxecto Rango límite en yaml, aplicalo a certos espazos de nomes e, a continuación, neste espazo de nomes podes dicir que tes recursos predeterminados, máximos e mínimos para os pods.
Coa axuda deste tipo, podemos limitar aos usuarios en espazos de nomes de produtos específicos dos equipos a capacidade de indicar todo tipo de cousas desagradables nas súas vainas. Pero, desafortunadamente, aínda que lle dis ao usuario que non pode lanzar pods con solicitudes para máis dunha CPU, existe un comando de escala tan marabilloso ou pode escalar a través do panel de control.
E de aí vén o método número dous. Lanzamos 11 pods. Son once mil millóns. Non se debe a que se me ocorrese un número así, senón a que o vin eu.
Historia real. A última hora da noite estaba a piques de saír da oficina. Vexo a un grupo de desenvolvedores sentados na esquina, facendo algo frenéticamente cos seus portátiles. Achégome aos mozos e pregúntolles: "Que che pasou?"
Un pouco antes, arredor das nove da noite, un dos desenvolvedores preparábase para volver a casa. E decidín: "Agora reducirei a miña solicitude a un". Premei un, pero Internet diminuíu un pouco. Premeu a un de novo, premeu a un e premeu Intro. Piquei todo o que puiden. Entón Internet cobrou vida e todo comezou a reducirse ata este número.
É certo que esta historia non tivo lugar en Kubernetes; naquel momento era Nomad. Rematou co feito de que despois dunha hora dos nosos intentos de impedir que Nomad se intentou escalar, Nomad respondeu que non deixaría de escalar e que non faría outra cousa. "Estou canso, voume". E acurrucábase.
Por suposto, tentei facer o mesmo en Kubernetes. Kubernetes non estaba contento con once mil millóns de vainas, dixo: "Non podo. Supera os protectores bucais internos". Pero 1 de vainas poderían.
En resposta a mil millóns, o Cubo non se retirou a si mesmo. Realmente comezou a escalar. Canto máis avanzaba o proceso, máis tempo lle levou crear novas vainas. Pero aínda así o proceso continuou. O único problema é que se podo lanzar pods de forma ilimitada no meu espazo de nomes, entón aínda sen solicitudes e límites podo lanzar tantos pods con algunhas tarefas que coa axuda destas tarefas os nodos comezarán a sumarse na memoria, na CPU. Cando lanzo tantos pods, a información deles debería ir almacenada, é dicir, etcd. E cando chega demasiada información, o almacenamento comeza a volver demasiado lentamente e Kubernetes comeza a ser aburrido.
E un problema máis... Como sabedes, os elementos de control de Kubernetes non son unha cousa central, senón varios compoñentes. En particular, hai un xestor de controladores, un planificador, etc. Todos estes rapaces comezarán a facer traballos innecesarios e estúpidos ao mesmo tempo, que co paso do tempo comezarán a levar máis e máis tempo. O xestor do controlador creará novos pods. Scheduler tentará atopar un novo nodo para eles. Probablemente quedará sen novos nodos no seu clúster en breve. O clúster de Kubernetes comezará a funcionar cada vez máis lento.
Pero decidín ir aínda máis alá. Como sabes, en Kubernetes existe tal cousa chamada servizo. Ben, por defecto nos teus clústeres, o máis probable é que o servizo funcione usando táboas IP.
Se executas mil millóns de pods, por exemplo, e despois usas un script para forzar a Kubernetis a crear novos servizos:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done En todos os nodos do clúster, xeraranse cada vez máis regras de iptables novas de forma simultánea. Ademais, xeraranse mil millóns de regras de iptables para cada servizo.
Comprobei todo isto en varios miles, ata dez. E o problema é que xa neste limiar é bastante problemático facer ssh ao nodo. Porque os paquetes, pasando por tantas cadeas, comezan a non sentirse moi ben.
E isto tamén se soluciona coa axuda de Kubernetes. Hai un obxecto de cota de recursos deste tipo. Establece o número de recursos e obxectos dispoñibles para o espazo de nomes do clúster. Podemos crear un obxecto yaml en cada espazo de nomes do clúster de Kubernetes. Usando este obxecto, podemos dicir que temos un certo número de solicitudes e límites asignados para este espazo de nomes, e entón podemos dicir que neste espazo de nomes é posible crear 10 servizos e 10 pods. E un só desenvolvedor pode polo menos atragantarse polas noites. Kubernetes dirálle: "Non pode escalar as súas vainas a esa cantidade, porque o recurso supera a cota". Xa está, problema resolto. .
A este respecto, xorde un punto problemático. Sentes o difícil que se está facendo crear un espazo de nomes en Kubernetes. Para crealo hai que ter en conta moitas cousas.
Cota de recursos + Rango límite + RBAC
• Crear un espazo de nomes
• Crear un límite dentro
• Crear cota de recursos dentro
• Crear unha conta de servizo para CI
• Crear vinculación de roles para CI e usuarios
• Opcionalmente, inicie os módulos de servizo necesarios
Por iso, gustaríame aproveitar esta oportunidade para compartir os meus desenvolvementos. Hai algo así chamado operador SDK. Esta é unha forma de que un clúster de Kubernetes escriba operadores para el. Podes escribir enunciados usando Ansible.
Ao principio escribiuse en Ansible, e despois vin que había un operador SDK e reescribín o rol de Ansible nun operador. Esta declaración permítelle crear un obxecto no clúster de Kubernetes chamado comando. Dentro dun comando, permítelle describir o ambiente para este comando en yaml. E dentro do ámbito do equipo, permítenos describir que estamos destinando tantos recursos.
Pequeno .
E en conclusión. Que facer con todo isto?
Primeira. A política de seguridade do pod é boa. E a pesar de que ningún dos instaladores de Kubernetes os usa ata hoxe, aínda debes utilizalos nos teus clústeres.
A política de rede non é só outra característica innecesaria. Isto é o que realmente se necesita nun clúster.
LimitRange/ResourceQuota: é hora de usalo. Comezamos a usar isto hai moito tempo, e durante moito tempo estiven seguro de que todos o estaban a usar. Resultou que isto é raro.
Ademais do que mencionei durante o informe, hai funcións non documentadas que che permiten atacar o clúster. Lanzado recentemente .
Algunhas cousas son tan tristes e ferintes. Por exemplo, en determinadas condicións, os cubelets nun clúster de Kubernetes poden dar o contido do directorio warlocks a un usuario non autorizado.
Hai instrucións sobre como reproducir todo o que che dixen. Hai ficheiros con exemplos de produción do aspecto da política de seguranza de ResourceQuota e Pod. E podes tocar todo isto.
Grazas a todos.
Fonte: www.habr.com