RU1064 – База знаний – Сервер документации Рутокен

Что использовать для локальной разработки под kubernetes?

ВИКТОР ГАМОВ: Давайте по тулам поговорим. Здесь был вопрос, мне очень он нравится самому: «Что думаете по поводу k3s как способе развернуть кластер и разобраться в его устройстве?».

СЕРГЕЙ БОНДАРЕВ: Это детище компании Rancher. k3s заявлялся как Kubernetes, который будет запускаться «на холодильнике».

ВИКТОР ГАМОВ: Это такая штука, которая полностью обрезана.

СЕРГЕЙ БОНДАРЕВ: У него отрезано не так уж и много. Вырезаны облачные контроллеры и прочее, но самое главное, у него вырезан etcd, вместо него используется SK Light, и всё это работало на одной-единственной машинке, грубо говоря. Использовать эту штуку для изучения Kubernetes не самый лучший вариант.

ВИКТОР ГАМОВ: То есть ты поклонник подхода Kubernetes the Hard Way? Когда нужно пойти и разобраться.

СЕРГЕЙ БОНДАРЕВ: Я поклонник установки с помощью kubespray.

ВИКТОР ГАМОВ: А ведь мы не сказали, что Сергей Бондарев — один из тех, кто коммитит в kubespray.

СЕРГЕЙ БОНДАРЕВ: Я в нём разбираюсь, время от времени чиню баги и дополняю функционал.

ВИКТОР ГАМОВ: Раз уж мы заговорили про тулы внедрения. Какая там сейчас обстановка? Раньше был «капс», теперь есть kubeadm, k3s, kubespray — что их отличает и что взять? Ты упомянул Minikube, но по моему опыту он достаточно капризный. Под MacOS, например, он очень странно жил.

СЕРГЕЙ БОНДАРЕВ: Это не ко мне вопрос. У меня всегда есть несколько виртуалок с Docker, которые объединены в локальную сеть. Я на них могу поставить что угодно. Необходимости поставить что-то на локальном компьютере у меня не возникает.

ВИКТОР ГАМОВ: k3s был популярен, потому что в нём обрезаны многие лишние вещи. Например, обратная совместимость…

СЕРГЕЙ БОНДАРЕВ: Ну как же! Обратная совместимость — это самое важное, что есть в Kubernetes.

Что для вас «знать kubernetes»?

ВИКТОР ГАМОВ: Что для вас знание Kubernetes? Знание ключей и опций kubectl? Архитектуры? Компонентов? Отличий от Docker и Docker Compose? Сертификаты CKA/CKAD? Расшифруйте, чтобы, выровнять понятийный уровень. Что важнее: сертификаты или опыт?

МАРСЕЛЬ ИБРАЕВ: Знания, конечно. Но сертификат — штука приятная. Вы можете указать длинный списочек: ваши регалии, грамоты школьные приложить.

ВИКТОР ГАМОВ: Какие сертификаты получат слушатели курса по Kubernetes для разработчиков? Или курс больше нацелен на получение практических знаний?

МАРСЕЛЬ ИБРАЕВ: Мы всегда делали акцент на практику. Наша цель не подготовить к сертификации, а подготовить к применению знаний на практике. В первую очередь знание, а нужен сертификат или нет, каждый решает сам.

СЕРГЕЙ БОНДАРЕВ: Система сертификации пришла к нам, наверное, с Запада. Она рассчитана на то, что незнакомый человек посмотрит на твою доску почета и проникнется, поймёт, что какой-то дядя проверил твои знания и выдал бумажку, что ты вот эту штуку знаешь хорошо.

С тех пор как за сертификацию начали брать деньги, это стало отдельным бизнесом. Ситуация такая: если я сделаю нормальную сертификацию, на которой задаются действительно сложные вопросы, никто не придет ее сдавать, я не получу своих денег, поэтому сертификацию мы делаем по низу средних способностей, чтобы хотя бы 70-80% людей, которые к нам приходят, ее сдавали.

Другая крайность — брать за сертификацию большие деньги, делать ее сложной и ожидать, что придет мало людей, но за этих людей будет платить работодатель. А компаниям, в которых работают крутые специалисты, сертификация особо и не нужна: они уже знают, что у них есть крутые специалисты, зачем их сертифицировать.

ВИКТОР ГАМОВ: Дима или Паша, когда к вам приходят соискатели на вакансию SRE или разработчика, вы смотрите на сертификаты? Или делаете прожарку тестовым заданием?

ДМИТРИЙ ЛАЗАРЕНКО: В MCS мы не смотрим на сертификаты. А смотрим на то, как человек подходит к решению проблемы, насколько попытается разобраться в причине, как коммуницирует с другими людьми (это уже история про софт-скилы), и в целом, насколько разбирается в архитектуре, понимает репликацию в базах данных или как работает Kubernetes.

Это лучше, чем просто формальная сдача экзамена на сертификат. Мы смотрим на problem-solving и на то, как ты коммуницируешь с другими людьми во время решения проблемы. Потому что герои-одиночки, которые могут быть токсичными, никому не интересны. Мы отказывали людям, которые не могут хорошо общаться с командой, но при этом очень крутые технические специалисты.

ПАВЕЛ СЕЛИВАНОВ: Когда проходишь собеседование и говоришь, что есть сертификат, обычно на это отвечают: «Ага, давайте к следующему вопросу». Мне кажется, сертификаты, особенно кубернетесовские, в основном нужны компаниям. Я работал в двух компаниях, у которых есть сертификация Linux Foundation от CNCF.

Соответственно, чтобы компании пройти такую сертификацию, в штате должно быть определённое количество специалистов, которые сертифицированы как администраторы или девелоперы Kubernetes. Это тот случай, когда реально стоит пройти CK или CKD. Если вы думаете, что CK или CKD поднимет зарплату или увеличит шансы устроиться на работу, то вы, вероятно, ошибаетесь. По крайней мере, в России на эту бумажку вообще никто не смотрит.

А что с безопасностью?

ВИКТОР ГАМОВ: Самый важный вопрос обсудить забыли: что у нас с безопасностью? Что есть в Kubernetes, что позволяет обеспечить безопасность.

ПАВЕЛ СЕЛИВАНОВ: В чатике как раз был вопрос, как в синергию админов и разработчиков вписать безопасников, то есть как сделать DevSecOps — как создавать тулы безопасников, как их встраивать в общий пайплайн.

Что вижу я: в крупных компаниях безопасник — это какой-нибудь отставной подполковник ФСБ, и последнее, что он делал, это «Эльбрусы» кольцом собирал. Задача безопасника — подписывать бумажки и брать на себя ответственность. Поэтому тут вообще вопрос: когда бизнес перестанет воспринимать безопасников как людей, которые подписывают бумажки, и начнет их как людей, которые должны интегрироваться с остальным техническим отделом и идти в ту же сторону, использовать какие-то инструменты.

Инструментов на сегодняшний день огромное количество. Мне как DevOps инженеру, человеку, который пишет пайплайны, было бы интересно всё это дело в свои пайплайны встраивать, просто времени не хватает. Я бы хотел, чтобы кто-то этим занимался. Но у самого Kubernetes есть airbag, это встроенная фишка.

Можно подключить какой-нибудь hashicorp vault, чтобы хранить секреты, это, наверное, самое распространенное. Есть еще штуки типа Open Policy Agent, который позволяет просматривать и писать конкретные правила под всё, что запускается в Kubernetes, делать свои собственные политики безопасности, настраивается все это очень гибко, проверяется и так далее.

Есть инструменты, которые добавляют просто авторизацию в кластер и делают это нормально, типа Keycloack, Dex. Есть штуки, которые позволяют анализировать содержимое контейнеров, то, что вы собираетесь деплоить на свои продакшен-серверы. Например, Harbor, JFrog и т д.

ВИКТОР ГАМОВ: Поддержу Пашу. Сегодня безопасность перестаёт быть чем-то загадочным из серии «мы сгенерировали ключи, запечатали в конверты и разослали». Есть набор совершенно понятных решений, которые надо внедрять. А вот всеми любимый Kerberos. Как делать Kerberos на Kubernetes?

МАРСЕЛЬ ИБРАЕВ: В Kubernetes точно есть инструментарий, который может с LDAP-ами всякими дружить, и делает это достаточно хорошо. Kerberos я не пробовал.

СЕРГЕЙ БОНДАРЕВ: Для Kerberos мы слишком молоды.

ДМИТРИЙ ЛАЗАРЕНКО: В Keycloak есть штука, которая позволяет обменивать токены одного типа, например, самловские токены в open d connect токены. И за счёт такого пайплайна обмена токенов Kerberos’а в open d connect, которые понимает Kubernetes, наверное, можно сделать подобный костыль.

ВИКТОР ГАМОВ. В завершение давайте ещё раз поговорим про тулы. Манифесты пишутся с использованием Helm, как разработчику упростить себе жизнь при работе с ним?

ПАВЕЛ СЕЛИВАНОВ: Могу поделиться, как мы сейчас делаем это в MCS. В третьем Helm есть библиотечные чарты, на базе которых мы собрали единый Helm-чарт. И фактически всё, что нужно знать разработчику, это посмотреть документацию к единому Helm-чарту, посмотреть, какие там есть вэльюсы, и в своем проекте заполнить просто один файлик с вэльюсами (на самом деле, не один, а по одному файлику на каждое окружение). Они еще между собой мёрджатся.

Благодаря этому разработчики не касаются Kubernetes, при этом мы применяем все best practices, которые хочется применять к манифестам, используемым разработчиками. Фактически мы из этих вэльюсов разработки генерим готовые чарты. Точнее, подставляем их в наш общий чарт и деплоим это в кластер. Вот как упрощается жизнь разработчика: они не касаются Helm’a и Kubernetes’a вообще никаким образом.

За что отвечают разработчики, а за что devops при работе с kubernetes? кто более компетентен?

ВИКТОР ГАМОВ: Вот Паша говорит, что разработчики должны поддерживать то, что они написали. Как по мне, это история не про поиск виноватых, а про делегирование и доверие команде. Когда людям предоставляют возможность доказать, что они могут, они начинают немного по-другому мыслить. Начинают работать не «с девяти и до обеда», а ради цели.

ДМИТРИЙ ЛАЗАРЕНКО: Это про вовлечение разработчиков, когда они перестают быть кодерами и становятся архитекторами сервисов. Они становятся причастными к созданию чего-то великого, ну и к провалам в том числе, — если что-то идет не так.

ВИКТОР ГАМОВ: Поэтому мне всегда больно видеть термин DevOps в значении «человек», а не в значении «культура». Необходимо изменять сознание и подходы к тому, как работают люди, иначе никакие технологии нам не помогут. Нам необходимо менять культуру и восприятие людей. Кто со мной поспорит?

СЕРГЕЙ БОНДАРЕВ: Культура, конечно, вещь хорошая, но не главная. Ты можешь быть сколь угодно культурным, но если у тебя нет компетенций, тебя ждут только великие провалы.

ВИКТОР ГАМОВ: То есть тот, кто более компетентен, тот и берёт на себя ответственность? Есть админы, есть опсы, кто из них важнее на проекте?

СЕРГЕЙ БОНДАРЕВ: Наверное, никто из них. Продукт оунер, скорее.

ПАВЕЛ СЕЛИВАНОВ: Архитектурный комитет.

ВИКТОР ГАМОВ: Ага, то есть никто. Если есть архитектурный комитет, то дело может сильно затянуться. Марсель, у тебя какие соображения?

МАРСЕЛЬ ИБРАЕВ: Соглашусь, что никто не главный, но зоны ответственности разные. Есть инфраструктурная команда, и все-таки ключевые решения по инфраструктуре, я думаю, за ними. А разработчики уже решают, что и как кодить под эту инфраструктуру, какие инструменты использовать. При этом в идеальном мире должна происходить синергия, и решаться всё это должно не лоб в лоб, а сообща.

ВИКТОР ГАМОВ: Я ждал, кто первым скажет слово «синергия». Ты выбиваешь булшит-бинго!

ДМИТРИЙ ЛАЗАРЕНКО: Я добавлю. Паша говорил про архитектурный комитет. В чём сложность ситуации? Вот откройте карту CNCF: там сотни проектов, сотни сервисов, и все это новое. В реальности мало кто годами использовал, например, Istio. И на вопрос, кто главный при выборе Istio, ответ: «да хрен его знает».

ВИКТОР ГАМОВ: Я сейчас вброшу, а вы поспорьте со мной. В чём DevOps меняет восприятие разработки, так это в том, что можно проводить эксперименты и изучать технологии прямо в процессе. Благодаря Kubernetes мы можем делать AB-тестинг: например, на одной части контура использовать Istio, на другой части ещё какого-нибудь вендора.

ПАВЕЛ СЕЛИВАНОВ: Вот именно, что Kubernetes — это не законченная вещь, это конструктор, который нужно собрать под себя. Я видел в нескольких проектах такое разделение: некие мифические DevOps’ы строят платформу для разработки, чтобы разработчик мог как можно меньше заморачиваться на этапе разработки по поводу инфраструктурных моментов, меньше ломать, если что-то пойдет не так, и как можно более гибко её использовать.

СЕРГЕЙ БОНДАРЕВ: Можно мне поныть на тему изучения новых технологий. Неумеренность в этом вопросе приводит к тому, что приходишь на проект, видишь кучу новых слов, начинаешь в них разбираться, и оказывается, что часть технологий уже прекратила своё развитие, часть из них ещё в глубокой альфе.

ВИКТОР ГАМОВ: Тут речь как раз про культуру. Когда в команде есть доверие, сложные вопросы решаются легче.

Что будет на курсе?

ВИКТОР ГАМОВ: Давайте конкретики добавим: что будет на курсе, что поможет, например, Java-разработчику разбираться глубже в вопросе деплоя?

МАРСЕЛЬ ИБРАЕВ: Кстати, вопрос, который был на слайде: «что есть Kubernetes?» Мы как-то без конкретики его пробежали. Можем вернуться и поконкретнее рассказать.

Что нужно знать разработчику: это, разумеется, основные абстракции куба — в чем ваше приложение запускается и какие инструменты поддерживаются. Далее, вы хотите, чтобы ваше приложение работало только со stateful-данными, или вы хотите, чтобы ваше приложение запускалась на каждой ноде кластера, — все это разные абстракции.

Их определенно нужно знать и админам, и разработчику. Банальный пример: что-то не заработало, надо срочно фиксить. Инфраструктура, конечно, полезет и на крайний случай откатит. Но факт, что проблема возникла после деплоя, намекает: проблема может быть в коде, надо садиться и разбираться. Разбираться лучше уже на стейдже, поэтому какая-то база в голове должна быть.

ПАВЕЛ СЕЛИВАНОВ: Про курсы любят спрашивать: «а что мне на курсе расскажут такого, чего нет в документации? зачем мне эти курсы нужны?». Я могу ответить, что в этом курсе гарантированно есть вещи, которых нет в документации.

Среди присланных вопросов был вопрос, как дебажить Java или что-то такое. Это вообще распространенная в Kubernetes штука: у вас есть продакшен, и естественно разработчики хотят прийти на продакшен, залезть в контейнеры и начать там на живых пользователях что-то дебажить. Вот что нужно знать разработчику про Kubernetes.

Про абстракции, джобы, стейтфул-сеты можно почитать документацию — недельки чтения будет достаточно. А вот реальная эксплуатация кластера Kubernetes и задачи разработки… С этими задачами вам админы не пойдут помогать. Как ваше приложение дебажить, какие инструменты для этого есть, как вам построить локальную разработку так, чтобы код, который вы пишете, одинаково хорошо работал в Docker, Docker-compose, Kubernetres и так далее. Как это все собирать между собой. Вот это те вещи, которые мы хотим разобрать в курсе.

Certified kubernetes application developer (ckad) exam | linux foundation

During the exam

In the exam, please be fresh, drink a lot of water and make sure you have eaten well. because for the next 3 hours you will not be allowed to even drink water. Please make sure you have a stable internet connection and no interruptions.

Getting prepared

First I advice you to download the exam study guide book and get a thorough understanding of what is required of you.

I followed the CKA prep course offered by Linux Academy here to gather and fine tune my knowledge according to the requirements of the exam study guide. Please note that watching this course alone will not guarantee you getting through.

Once you feel like you are ready to go, please go try out the following practice questions to get yourself better prepared. Note that this is targeted towards CKAD and not CKA, but still, doing these questions helped me a lot in getting prepared.

Take a look at this too.

Another important thing to do at-least more than 3 times is Kelsey Hightower’s Kubernetes the Hard way Guide which is provided below. Please make sure not to copy paste anything here and try to type everything manually and try to understand what is happening at each and every step.

In addition to that, please familiarize yourself a bit on systemd here if you don’t know what it does.

Okay that’s pretty much it on what I did for in terms of preperation for the exam. One thing to note though, I only did kelsey’s Kubernetes the hardway only one time, and that too I just copy pasted the commands without really trying to understand what’s happening behind those commands. I paid my price for that in some questions in the exam.

UPDATE:Recently one of my friends sent me this article, which has 150 sample questions for CKAD. Please have a look at this too.

Kcsp details

The main benefits of becoming a KCSP are:

Requirements are:

The CKA exam is an online, proctored, performance-based test that requires solving multiple issues from a command line. It takes 3 to 4 hours to complete, and costs $375.

Kcsp process

If your company is interested in becoming a KCSP, please complete the following steps:

Keep your score

In the exam, you get a notepad, where you can enter whatever you like. You can use this to save some kubectl commands for future references etc. However, another thing that I recommend you do is, once you complete a question, write down number of the question, the marks for that question and your total marks. This way, you will always know where you are with relevant to your score.

This is handy in the final hour as you absolutely know how many questions you have attempted and how much minimum marks you need to achieve that pass mark of 74%. You don’t have to complete all the 24 questions you get to pass the exam, just target on getting that 74% and use your time to double check answers without attempting all.

I did 22/24 and used the final half an hour to double check my answers before trying to attempt questions 23 and 24. And thank god i did, because some questions, I have forgotten to change context at the top and some text files that I should have saved in the base vm, I have saved in a node that I have ssh’d into and have forgotten to exit properly.

Kubectl it away!

Don’t try to write your own yamls at the exam. Avoid that as much as possible and use kubectl as much as you can. There’s a lot you can do on kubectl alone.

If you are unsure of the spec or parameters of a yaml, always use

kubectl explain <resource>.<key>

which is a great way to get a quick look at the keys available to you.

Pay attention to the question context

You will get a context change command at the beginning of every question to change the kubctl context as each question may refer a different cluster than your previous question. So always as a practice change the context before attempting a new question.

Ru1064 – база знаний – сервер документации рутокен

Take it easy and all the very best!

Don’t stress out much on the exam. True, it’s hard. Don’t panic. I panicked at the last minute before starting the exam and tried to reschedule for a later date thinking I was not ready. However it was too late and I just took a deep breath and thought, what the hell, I’ll just go for it and I did. Don’t be scared as you get a free retry on the exam. Thankfully, I passed on the first attempt itself.

That’s pretty much it for my tips and tricks for taking the CKA. I wish you all good luck on the exam. Let me know if you have more queries. Clap and show your support. Cheers!

Useful websites

During the exam, you will get a browser based terminal and it will have all the tools you are required to have. You can only open one more tab and can go to any website under the domain of kubernetes.io. Here are the following links that helped me the most during the exam.

В какой момент среднестатистическому разработчику стоит задуматься об умении использовать kubernetes?

ВИКТОР ГАМОВ: Стоит ли полагаться на разработчиков при внедрении или лучше найти DevOps-инженера?

ПАВЕЛ СЕЛИВАНОВ: Что касается внедрения Kubernetes и вообще любых инфраструктурных вещей… Если вы стартап, вам надо просто запуститься и показать, какая ваша разработка крутая, то можно обойтись без выделенного человека. Дальше, я боюсь, если вы не наймёте такого человека, то у вас в команде быстренько найдется разработчик, на которого все это свалится.

Отвечая на вопрос, насколько разработчику вообще необходимо уметь использовать Kubernetes, — я бы не стал этим заморачиваться до тех пор, пока в компании нет Kubernetes или нет возможности его использовать. Но как только админы или DevOps припрут Kubernetes, вам так или иначе придётся с ним разобраться.

ВИКТОР ГАМОВ: Ты ведь из облачного провайдера, почему ты не говоришь, что cloud-провайдер даёт тебе не просто голый Kubernetes, a managed-Kubernetes, снимает головняк?

ДМИТРИЙ ЛАЗАРЕНКО: Дьявол в деталях. Наверное, самое интересное начинается, когда вы внедрили Kubernetes и первый раз прилёг продакшен. Что происходит потом, можно долго описывать. Разработчик должен понимать все эти примитивы внутри Kubernetes, он должен понимать интеграцию с разными инструментами:

Без понимания эксплуатации всё становится грустно, и приложение чинится сутками. DevOps’ы не понимают бизнес-логику работы приложения, а разработчики не понимают, как работает Kubernetes и что там сломалось. Одна из ключевых проблем, которая была в начале с OpenShift, в том, что никто не понимал, как вся эта машина работает.

ВИКТОР ГАМОВ: То есть ты хочешь сказать, что мало знать Java, например, или Golang, и разбираться, как алгоритмы на них написать, ещё нужно понимать, где и как это будет выполняться? Мало того что это будет выполняться в какой-то среде, так эта среда ещё не настоящая. Потому что вокруг этой среды ещё много всего.

ДМИТРИЙ ЛАЗАРЕНКО: Не совсем так. Kubernetes в этом отношении даёт унификацию. В целом понятно, какая среда — повторяемая. Пускай даже используются разные облачные провайдеры, но в целом все работает более-менее одинаково. Но среда всё равно непривычная, другая. Там ещё много всего вокруг, и оно может стрельнуть.

ВИКТОР ГАМОВ: Может быть, стоит провайдеру снимать эти головняки? У нас есть админы, которые умеют готовить Kubernetes, есть разработчики, которые в принципе знают, как писать приложение, но ещё им нужно понимать, как варить Kubernetes. Может быть, их кто-то встретит как раз хорошим сервисом, чтобы уменьшить головняк?

ДМИТРИЙ ЛАЗАРЕНКО: Идея хорошая, но это как с безопасностью. Если всё будет безопасно, работать будет невозможно. За всё приходится платить. За автоматизацию, о которой ты говоришь, приходится платить очень жёсткими правилами. К сожалению или к счастью, у нас мультикультурное общество, каждый думает по-своему, и невозможно придумать унифицированные правила для работы приложения.

Все пытаются это делать, изобретают фреймворки, но идея утопична. Всякие спинакеры и подобные продукты позволяют унифицировать и упростить процесс CI/CD. Но это не единственный процесс. Обилие open source инструментов делает задачу нерешаемой. Да, облачный провайдер упрощает жизнь и позволяет системным администраторам и DevOps экономить время на выполнении рутинных операций, но это не серебряная пуля.

СЕРГЕЙ БОНДАРЕВ: Cloud-провайдеры предоставляют набор готовых решений, в которые ты волей-неволей должен упихиваться. Если тебя этот набор удовлетворяет, то в принципе жить в облаке не проблема. Но иногда есть потребности или идеи, которые в облаке реализованы не так, как ты хотел.

И ты отказываешься от каких-то частей cloud-решений, потому что они тебя не удовлетворяет по своим возможностям и своим ограничениям. Кроме того, облачные решения консервативны. Если что-то сломалось, чинить это будут долго. А сам ты себе это можешь поставить и нормально работать.

ВИКТОР ГАМОВ: Да, такое будет в любой managed-системе.

Зачем перегружать разработчика информацией, когда можно просто дать ему кнопку?

ПАВЕЛ СЕЛИВАНОВ: Это такой комплексный вопрос, столько сразу слоев. Давайте представим ситуацию: у нас есть бизнес, техническая команда решила, что им нужен Kubernetes, и вся бизнес-разработка останавливается, пока DevOps’ы не напилят кнопку, которая удовлетворит все потребности разработчиков.

Я думаю, что это нереальная ситуация. В любом случае разработчики будут жить с Kubernetes, сами будут с ним разбираться. Со временем, наверное, это взаимодействие будет уменьшаться, но я не верю, что это произойдёт быстро и разработчик избавится от необходимости знакомиться с Kubernetes.

Опять же, Kubernetes, да и микросервисы вообще, позволяют выкатывать фичи быстро. Так быстро, как это нужно бизнесу, при этом не сильно заморачиваться, как что-то работает под капотом. Гораздо проще написать простой микросервис, какую-нибудь фиговину, которая будет базу данных перекладывать в информацию в формат Json, чем действительно разбираться с новыми или старыми технологиями и писать что-то низкоуровневое. Мне кажется, Kubernetes как раз-таки позволяет удовлетворять современные требования бизнеса.

МАРСЕЛЬ ИБРАЕВ: Тут, конечно, вопрос, как Паша сказал, многослойный. И без привязки к кому-то примеру сложно сказать. Но если мы хостим всё у себя, без облаков, и при этом мы говорим, что у нас DevOps, то, мне кажется, DevOps у нас не получится, если не будет тесной взаимосвязи и понимания, что делает разработка, а что админы.

Как я сдавал certified kubernetes security

Всем привет.

Хочу поделиться своим опытом успешной сдачи экзамена Certified Kubernetes Security (CKS) от Linux Foundation. Данный экзамен, как нетрудно догадаться, проверяет наши способности настраивать различные аспекты безопасности кластера Kubernetes и приложений, работающих в нем. Экзамен мне понравился, он рассматривает безопасность с различных точек зрения, а также использует очень полезные внешние инструменты, такие как Falco, Trivy, kube-bench, Open Policy Agent, gVisor и др. Сам экзамен мне показался умеренно сложным, в отличие от CKA, который больше ориентирован на новичков в Kubernetes.

Вначале я расскажу в целом об экзамене и подготовке к нему, а затем перейду к темам, затрагиваемым на экзамене.

На текущий момент существует всего два экзамена по безопасности Kubernetes – это, собственно, сам CKS, а также Red Hat Certified Specialist in Security: Containers and OpenShift, имеющий дело с безопасностью OpenShift. Эти два экзамена во многом пересекаются, однако по Опеншифту я считаю экзамен все же сложнее (его я благополучно завалил).

Экзамен отдельно стоит стоит 300$, официальный курс Kubernetes Security Fundamentals (LFS260) стоит 299$, можно купить курс и экзамен вместе за 499$. Я купил курс и экзамен вместе за 200$ на традиционной предновогодней распродаже от Linux Foundation.

Необходимым условием для сдачи CKS является наличие действующего сертификата CKA (Certified Kubernetes Administrator). Вы можете купить CKS, но не сможете назначить экзамен, пока не получите CKA. Звучит логично, поскольку экзамен CKS является гораздо более сложным чем CKA.

Но ближе к делу. Для подготовки я использовал два курса:

1. Официальный курс от Linux Foundation: Kubernetes Security Fundamentals (LFS260). Не хочу ничего плохого говорить о Linux Foundation, но данный курс у них вышел неудачным. Нет внятного объяснения, как работает та или иная технология или фича, сначала несколько общих красивых слов о том, какая это крутая технология, а затем сразу какая-то невнятная лаба в PDF (вы что, серьезно?!), в которой также ничего толком не объясняется. Такое ощущение, что курс делали в последнюю минуту в большой спешке. Притом, что экзамен получился очень даже неплохим.

2. Курс на Udemy за 3599 руб. Признаться, я сильно опасался покупая “кота в мешке”, однако реальность превзошла все ожидания. Курс оказался не просто полезным, он полностью раскрыл все темы экзамены, смотрелся просто на одном дыхании. К курсу прилагаются также два тестовых экзамена на https://killer.sh. Это полноценные лабы очень похожие на то, что встретится на реальном экзамене, т.е. браузерный веб-терминал справа и задачи слева. Как уверяет автор курса, эти лабы являются на самом деле усложненной версией экзамена, т.е. если вы сделаете эти лабы, то экзамен вы точно сдадите. Как выяснилось, автор был совершенно прав.

Про сертификаты:  Промокоды Периодика декабрь 2021! Коды, купоны, скидки и акции

Экзамен состоит из 15-20 вопросов, продолжительность экзамена ровно 2 часа т.е. в среднем 6-8 минут на каждый вопрос. Это довольно сжатые сроки. Лично я, имея много опыта с Kubernetes и просмотрев два курса и сделав два тестовых экзамена на killer.sh, уложился в 1 час 40 минут.

Проходной балл на экзамене 67%, что на мой взгляд довольно демократично. Экзамен легким не назовешь, но низкий проходной балл видимо призван сгладить этот “недостаток”.

В комплекте с экзаменом идет одна бесплатная пересдача. Это очень круто и здорово успокаивает нервы, облегчая подготовку.

Теперь самое интересное – темы экзамена. Официальный список тем можно посмотреть на странице описания CKS. На всякий случай продублирую его здесь:

Список тем экзамена

Cluster Setup (10%)

1. Use Network security policies to restrict cluster level access

2. Use CIS benchmark to review the security configuration of Kubernetes components (etcd, kubelet, kubedns, kubeapi)

3. Properly set up Ingress objects with security control

4. Protect node metadata and endpoints

5. Minimize use of, and access to, GUI elements

6. Verify platform binaries before deploying

Cluster Hardening (15%)

1. Restrict access to Kubernetes API

2. Use Role Based Access Controls to minimize exposure

3. Exercise caution in using service accounts e.g. disable defaults, minimize permissions on newly created ones

4. Update Kubernetes frequently

System Hardening15%

1. Minimize host OS footprint (reduce attack surface)

2. Minimize IAM roles

3. Minimize external access to the network

4. Appropriately use kernel hardening tools such as AppArmor, seccomp

Minimize Microservice Vulnerabilities (20%)

1. Setup appropriate OS level security domains e.g. using PSP, OPA, security contexts

2. Manage Kubernetes secrets

3. Use container runtime sandboxes in multi-tenant environments (e.g. gvisor, kata containers)

4. Implement pod to pod encryption by use of mTLS

Supply Chain Security20%

1. Minimize base image footprint

2. Secure your supply chain: whitelist allowed registries, sign and validate images

3. Use static analysis of user workloads (e.g.Kubernetes resources, Docker files)

4. Scan images for known vulnerabilities

Monitoring, Logging and Runtime Security20%

1. Perform behavioral analytics of syscall process and file activities at the host and container level to detect malicious activities

2. Detect threats within physical infrastructure, apps, networks, data, users and workloads

3. Detect all phases of attack regardless where it occurs and how it spreads

4. Perform deep analytical investigation and identification of bad actors within environment

5. Ensure immutability of containers at runtime

6. Use Audit Logs to monitor access

Признаться, когда я вначале прочитал данный список, то подумал, что экзамен будет невозможно сдать – слишком много тем и все очень обширные. Но потом подумал, что скорее всего многие темы будут освещены в курсе, а в экзамен не попадут. Примерно так и вышло.

Экзамен реально интересный и при подготовке я узнал много нового. Больше всего мне понравилась тулза под названием Falco от Sysdig. Эта тулза мониторит системные вызовы ядра Linux и поднимает алерты, если обнаруживает подозрительную активность. В комплекте с Falco идет множество полезных предустановленных правил, например:

1. Запуск привилегированного контейнера или запуск контейнера с hostPID или hostNetwork

2. Попытка контейнера примонтировать важные хостовые директории через hostPath

3. Попытка повышения привилегий процессом в контейнере

4. Попытка процессов читать или писать в важные системные файлы, например в каталоге /etc

5. Попытка открыть сетевое соединение с IP-адресами не из разрешенного списка

6. Установка пакетов в контейнере

и многие другие.

Помимо этого, Falco поддерживает мониторинг аудит логов Kubernetes, позволяя поднимать алерты в случае подозрительной активностей на уровне Kubernetes API, например:

1. Создание привилегированного контейнера или запуск контейнера с hostPID или hostNetwork.

2. Создание неймспейсов

3. Запуск контейнера не из разрешенного списка имейджей

4. Запуск подов в неймспейсе kube-system

5. Создание ClusterRoleBinding с cluster-admin кластер ролью

и опять же многие другие.

При этом важно обратить внимание, что Falco по факту не может ничего запретить. Это лишь инструмент для анализа аудит логов, т.е. он постфактум дает представление о том, что уже произошло. Тем не менее, Falco оказался действительно очень мощным и полезным инструментом, о котором я не знал до начала подготовки к экзамену.

Если мы хотим иметь больше контроля над изменениями в кластере Kubernetes, при этом стандартного RBAC нам недостаточно, то в курсе описывается еще один инструмент под названием Open Policy Agent (OPA). Этот инструмент позволяет отслеживать соответствие объектов в Kubernetes определенным политикам безопасности, которые описываются на языке описания политик Rego. В Kubernetes он ставится в виде validating admission webhook под названием OPA Gatekeeper. Сами политики описываются в виде Custom Resource Definition. Вот пример политики, которая требует при создании или изменении неймспейса обязательного наличия лейбла costcenter.

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLabels
      validation:
        openAPIV3Schema:
          properties:
            labels:
              type: array
              items: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlabels
        
        violation[{"msg": msg, "details": {"missing_labels": missing}}] {
          provided := {label | input.review.object.metadata.labels[label]}
          required := {label | label := input.parameters.labels[_]}
          missing := required - provided
          count(missing) > 0
          msg := sprintf("you must provide labels: %v", [missing])
        }
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: ns-must-have-costcenter
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Namespace"]
  parameters:
    labels: ["costcenter"]

При попытке создания неймспейса без лейбла costcenter вылезет ошибка:

Error from server (you must provide labels: "costcenter"): error when creating "ns.yaml": admission webhook "validating-webhook.openpolicyagent.org" denied the request: you must provide labels: "costcenter"

Возможности OPA Gatekeeper постоянно расширяются, например он может работать в режиме аудита, т.е. лишь информировать об объектах Kubernetes, которые не соответствуют политике, но не запрещать их создание. Помимо этого, существует возможность переключить Gatekeeper в режим mutating webhook, т.е. автоматически приводить объекты в соответствие политике, например добавлять нужные лэйблы.

Кстати, у языка Rego есть собственный playground, в котором можно потестировать политики. Также, там есть ряд примеров политик для Kubernetes, что очень удобно.

Следующий инструмент, который показался мне полезным, это сканер уязвимостей контейнеров Trivy от Aquasecurity. В принципе, инструмент полезный, вроде как база уязвимостей у него шире, чем у того же Clair, но по большому счету все эти тулзы похожи.

Другие темы экзамена:

1. Network Policy. Тут все довольно просто, однако нужно знать про один важный нюанс from и to селекторов. В целом проблем с сетевыми политиками возникнуть не должно.

2. RBAC. Очень важно понимать разницу между Role и ClusterRole, RoleBinding и ClusterRoleBinding. Также надо помнить, что с ClusterRole можно создать ClusterRoleBinding, в этом случае эта роль будет действовать на всем кластере, а можно создать и простой RoleBinding, в таком случае ClusterRole будет действовать только в пределах одного неймспейса (самый частый пример, это кластерные роли admin, edit и view, которые можно давать юзерам на конкретные неймспейсы).
   В отличие от этого с Role можно создавать только RoleBinding, то есть простая роль всегда существует и ограничена неймспейсом, в котором она существует. Существование двух ролей с одним именем в двух разных неймспейсах совершенно легально, хотя вряд ли это можно назвать хорошей практикой.
   Также, очень важно понимать, для чего нужны сервисаккаунты, и как можно авторизовываться в кластере с их токеном (“Authorization: Bearer $TOKEN” и все такое).

3. Аудит логи Kubernetes. Нужно уметь настраивать аудит логи как в связке с Falco, так и простое логирование в файл. Нужно уметь писать политику аудита, также иметь представление о флагах kube-apiserver, которые связаны с настройками аудит логов.

4. Kube-bench. Нужно уметь пользоваться тулзой и исправлять найденные тулзой потенциальные бреши в безопасности кластера.

5. Уметь работать с флагами запуска kube-apiserver, kube-scheduler, kube-controller-manager и kubelet. Поскольку в экзамене встречаются только кластеры, созданные с помощью kubeadm, то исправление манифестов не представляет большого труда. Нужно только помнить о том, что если после исправление манифеста, компонент в течение минуты не запускается, то нужно идти и смотреть логи (/var/log/pods/*), т.к. скорее всего допущена опечатка или ошибка в манифесте.

6. Апгрейд kubeadm кластера.

7. Статический анализ безопасности YAML-манифестов Kubernetes и Докерфайлов. Здесь нужно просто смотреть глазами и находить потенциально небезопасные участки кода, например запуск контейнера от рута, использование секретов, излишние привилегии и др.

8. TLS-enabled Ingress.

9. ImagePolicyWebhook.

10. AppArmor. Нужно уметь включить профиль AppArmor на ноде и запустить под с данным профилем. Писать профили с нуля уметь не нужно (фух!)

11. Seccomp. Требование те же, что и с AppArmor.

12. Запускать поды с альтернативными RuntimeClass, типа gVisor. Знать, как их устанавливать, не нужно.

13. PodSecurityPolicy. Нужно помнить, что PodSecurityPolicy частично носит запрещающий характер, т.е. может отклонять поды с небезопасными настройками, но также частично может вносить изменения в настройки подов, например принудительно запускать поды с AppArmor профилями и управлять дефолтными настройками, например defaultAllowPrivilegeEscalation и defaultAddCapabilities.

14. Kubernetes Dashboard. Полезно изучить флаги запуска Kubernetes Dashboard, которые имеют отношение к безопасности, режим авторизации в дашборде.

Во время экзамена можно открывать одну и только одну дополнительную вкладку браузера с документацией (кстати, у меня экзамен не запустился на Chrome, пришлось установить Vivaldi). Разрешены следующие ресурсы:

1. https://kubernetes.io/docs

2. https://github.com/kubernetes

3. https://kubernetes.io/blog

4. https://github.com/aquasecurity/trivy

5. https://docs.sysdig.com

6. https://falco.org/docs

7. https://gitlab.com/apparmor/apparmor/-/wikis/Documentation

В принципе, этих ресурсов более чем достаточно. Большая часть всего необходимого всегда находится на https://kubernetes.io/docs.

Надеюсь, статья была полезной и поможет вам успешно получить сертификат Certified Kubernetes Security.

Когда компании пора внедрять kubernetes?

ВИКТОР ГАМОВ: В своих подкастах и шоу я всегда говорю, что мы как разработчики должны помогать бизнесу существовать. Все наши свистелки, моторчики и прочие клёвые штуки, которые мы сегодня нашли на GitHub, а завтра хотим отправить в прод, тоже должны работать на бизнес. Поэтому давайте подумаем, зачем компании Kubernetes и когда его пора внедрять?

ПАВЕЛ СЕЛИВАНОВ: У меня есть хороший ответ: когда CTO начитался Хабра и таки заметил слово «Kubernetes». Срочно нужно тащить к себе!

ВИКТОР ГАМОВ: Отлично. Еще какие версии? На самом деле, ребят, не делайте так. Технические решения внедряют, чтобы решить какую-то конкретную проблему. Какую проблему решает Kubernetes?