AZ-400: Designing and Implementing Microsoft DevOps Solutions - PASSED
Пока я раскачивалась на сдачу экзамена по ваучеру, полученному от завершения MS DevOps Challenge, на работе отсыпали пачку бесплатных ваучеров, плюс обучение по программе "Azure Enterprise Skills Initiative". Что же, тем лучше. Challenge accepted!
Вы, наверное, удивитесь, зачем безопаснику, даже "облачному", знать Dev[Sec]Ops, если уже усвоена OCI-модель. Но я уже поняла, что, живя бок о бок с разработчиками, какой только гадости не наберешься, начиная с кубернетеса и заканчивая разными мелкими опенсорсными утилитами, которые они почти едневно тащат из сети, даже не удосужившись проверить их безопасность для инфраструктуры, например, по OSSF Scorecard.
Так что периодические тренинги в смежных областях - это своеобразный способ борьбы с матрицей How your software profession is seen by other professionals.
Что полезного я вынесла из тренинга [помимо различных merge-стратегий для git, которые меня заинтересовали как математика, но вряд ли пригодятся IRL]:
1. Azure DevOps поддерживает работу с GIT Enterprise для тех компаний, которые хотят хранить свои исходники on-premises (не то чтобы хотят, но имеют высокие требования по compliance). Если бы я знала это раньше, то сэкономила бы кучу нервов на войне с юристами, предложив такое техническое решение (правда, был бы риск быть убитой разработчиками, вынужденными поддерживать on-prem инфраструктуру)
2. Оказывается, Azure Vault - не единственное место, где хранятся все "секреты" в Azure. Помимо этого, есть:
- Git Actions Secrets
- Azure Pipeline secrets
- Azure Artifacts Credential Provider
- Secure files, variable groups and service connections
И это не считая 3rd party solutions, типа Hashicorp Vault (и не считая Azure AD, на которую завязана большая часть IAM/RBAC)
Если этого не знать, а просто отправлять всех в баню к Vault, а потом выяснится, что такое решение технически реализовать невозможно / не является best practice, то есть риск, что авторитет ыксперда пострадает. Но более вероятно, что разрабы будут кивать головами, по факту продолжая постить конфиги с секретами прямо в репозиторий, а потому нелишним будет знать про такую утилиту как BFG Repo Cleaner, которая позволяет подчистить историю коммитов, если вдруг выяснилось, что в одном из них был выложен пароль или api key.
3. Роль Azure AD в DevOps сильно преувеличена. Я всегда считала, что могу полностью управлять доступом к Git, интегрированному с Azure, посредством AD. А тут выясняется, что "Azure AD credentials don't give access to git via command-line tools - use SSH keys". Плюс еще есть Personal Access Tokens (PAT) для тех приложений, которые не могут быть зарегистрированы в Azure AD.
4. (условно-полезное) И снова всплыл вопрос managed identity vs service principal, который меня донимал еще со времен SC-300: Microsoft Identity and Access Administrator. Мало того, что MI постоянно переименовывают, так еще и очень часто в вопросах одно понятие заменялось другим, хотя, согласно последнему определению, a managed identity is a service principal of a special type that can only be used with Azure resources. То есть, часто подразумевается, что, создавая SP, ты автоматически создаешь MI, но это не всегда верно. Я так понимаю, что сами мелкомягкие путаются в своей же терминологии после стольких переименований.
5. И еще я узнала про такую вещь как GIT Large File Storage. То есть, если я разрабатываю политики безопасности или документирую какие-то процедуры, выкладываю их на Git WebPages, но при этом хочу добавить, например, word/excel document template, презенташку или pdf, то я могу использовать LFS.
Кстати, по результатам экзамена я набрала по 100% в категориях "Define and implement a continuous delivery and release management strategy" и "Develop an instrumentation strategy", но только 75% в "Develop a security and compliance plan", что заставляет задуматься :)
Вы, наверное, удивитесь, зачем безопаснику, даже "облачному", знать Dev[Sec]Ops, если уже усвоена OCI-модель. Но я уже поняла, что, живя бок о бок с разработчиками, какой только гадости не наберешься, начиная с кубернетеса и заканчивая разными мелкими опенсорсными утилитами, которые они почти едневно тащат из сети, даже не удосужившись проверить их безопасность для инфраструктуры, например, по OSSF Scorecard.
Так что периодические тренинги в смежных областях - это своеобразный способ борьбы с матрицей How your software profession is seen by other professionals.
Что полезного я вынесла из тренинга [помимо различных merge-стратегий для git, которые меня заинтересовали как математика, но вряд ли пригодятся IRL]:
1. Azure DevOps поддерживает работу с GIT Enterprise для тех компаний, которые хотят хранить свои исходники on-premises (не то чтобы хотят, но имеют высокие требования по compliance). Если бы я знала это раньше, то сэкономила бы кучу нервов на войне с юристами, предложив такое техническое решение (правда, был бы риск быть убитой разработчиками, вынужденными поддерживать on-prem инфраструктуру)
2. Оказывается, Azure Vault - не единственное место, где хранятся все "секреты" в Azure. Помимо этого, есть:
- Git Actions Secrets
- Azure Pipeline secrets
- Azure Artifacts Credential Provider
- Secure files, variable groups and service connections
И это не считая 3rd party solutions, типа Hashicorp Vault (и не считая Azure AD, на которую завязана большая часть IAM/RBAC)
Если этого не знать, а просто отправлять всех в баню к Vault, а потом выяснится, что такое решение технически реализовать невозможно / не является best practice, то есть риск, что авторитет ыксперда пострадает. Но более вероятно, что разрабы будут кивать головами, по факту продолжая постить конфиги с секретами прямо в репозиторий, а потому нелишним будет знать про такую утилиту как BFG Repo Cleaner, которая позволяет подчистить историю коммитов, если вдруг выяснилось, что в одном из них был выложен пароль или api key.
3. Роль Azure AD в DevOps сильно преувеличена. Я всегда считала, что могу полностью управлять доступом к Git, интегрированному с Azure, посредством AD. А тут выясняется, что "Azure AD credentials don't give access to git via command-line tools - use SSH keys". Плюс еще есть Personal Access Tokens (PAT) для тех приложений, которые не могут быть зарегистрированы в Azure AD.
4. (условно-полезное) И снова всплыл вопрос managed identity vs service principal, который меня донимал еще со времен SC-300: Microsoft Identity and Access Administrator. Мало того, что MI постоянно переименовывают, так еще и очень часто в вопросах одно понятие заменялось другим, хотя, согласно последнему определению, a managed identity is a service principal of a special type that can only be used with Azure resources. То есть, часто подразумевается, что, создавая SP, ты автоматически создаешь MI, но это не всегда верно. Я так понимаю, что сами мелкомягкие путаются в своей же терминологии после стольких переименований.
5. И еще я узнала про такую вещь как GIT Large File Storage. То есть, если я разрабатываю политики безопасности или документирую какие-то процедуры, выкладываю их на Git WebPages, но при этом хочу добавить, например, word/excel document template, презенташку или pdf, то я могу использовать LFS.
Кстати, по результатам экзамена я набрала по 100% в категориях "Define and implement a continuous delivery and release management strategy" и "Develop an instrumentation strategy", но только 75% в "Develop a security and compliance plan", что заставляет задуматься :)