Від чеклістів до GitOps: як ми побудували IAM Assistant у Slack

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Зібрали онбординг, оффбординг, перевірку доступів і видачу credentials в одному Slack-інтерфейсі.

Привіт! Мене звати Валерій Маньковський, за тайтлом DevOps-інженер, сьогодні буде трохи про керування доступами.

У більшості компаній це не виглядає як проблема — поки не починає займати занадто багато часу.

Онбординг нового інженера може розтягуватися на години або навіть дні: доступи до AWS, GitLab, Postman, Sentry, баз даних, внутрішніх сервісів. Частина з них видається через Terraform, частина через API, щось робиться руками, щось через чеклісти в Jira або повідомлення в Slack.

В результаті:

— DevOps і IT постійно виконують однотипні запити;
— доступи залежать від людської пам’яті та контексту;
— перевірка прав перетворюється на міні-розслідування;
— credentials пересилаються небезпечними способами або взагалі губляться.

У нашому випадку це виглядало як нескінченний потік дрібних задач. І стало зрозуміло, що проблема не в окремих діях, а в самому процесі.

Ми розглядали готові рішення (Vault, Teleport, Okta IGA), але вони або не покривали всі наші сценарії, коштували забагато, не вписувалися в GitOps-підхід, або були занадто важкими для нашого випадку.

Тому ми побудували IAM Assistant — не як «розумного бота», а як інтерфейс у Slack, який перетворює роботу з доступами на відтворюваний, контрольований і прозорий процес.

У цій статті я покажу, як ми це зробили: від перших сценаріїв до GitOps-інтеграції, безпечної видачі credentials і LLM-шару поверх усього цього.

Які задачі ми хотіли закрити

Ми свідомо не намагалися автоматизувати все одразу. На старті сфокусувалися на чотирьох практичних сценаріях:

1. Онбординг нового співробітника.

2. Оффбординг співробітника.

3. Перевірка та редагування поточних прав.

4. Повторна безпечна відправка credentials.

Останній сценарій виявився особливо важливим. На практиці розробники постійно втрачають доступ до збережених credentials: при зміні ноутбука чи то при видаленні локальних даних (таке враження що вони ніколи не чули про 1Password чи Keeper). Раніше це майже завжди дорівнювало запиту у DevOps або IT та виконанню ручних маніпуляцій. Ми хотіли закрити й цей потік, але так, щоб не перетворити Slack на канал передачі секретів відкритим текстом.

Чому ми пішли в Slack

Окремий портал виглядав гарним рішенням на папері, але в реальності майже всі операційні запити вже жили у Slack. Саме там менеджери ставили задачі, інженери уточнювали деталі, а DevOps отримували запити на доступи. Тому ми вирішили не створювати ще одну точку входу, а вбудувати асистента туди, де люди і так працюють щодня.

У результаті сценарій став доволі простим: користувач запускає slash-команду, асистент показує модальне вікно, збирає потрібні поля, валідує введення і запускає потрібний flow.

Доступ до IAM-асистента контролюється через Slack-канал, у якому він використовується. Ініціювати будь-які workflow можуть лише користувачі, додані до цього каналу — зазвичай це менеджери, DevOps та IT-команди. Такий підхід дозволяє спростити модель доступу без окремої системи авторизації, зберігаючи при цьому контрольоване коло ініціаторів.
При цьому доступ до каналу не означає автоматичного виконання дій — всі критичні операції проходять через approvals.

Додатково всі дії користувачів повністю логуються: фіксується, хто саме ініціював запит, які команди були виконані та які зміни були внесені. Це забезпечує прозорий аудит і дозволяє в будь-який момент відтворити повну історію взаємодії з асистентом.

Однаковий інтерфейс, різні механіки

Один із головних висновків у цьому проєкті був дуже прагматичний: не всі інтеграції потрібно насильно підганяти під один і той самий механізм.

На етапі побудови першої версії MVP у застосунок ми додали три основні домени: AWS, GitLab і DB. Для AWS і DB-сценаріїв асистент працює через YAML-конфігурації. Він читає відповідні файли, вносить зміни в декларативний опис користувачів або їхніх прав, після чого створює окрему гілку, коміт та МР.

Важливо зазначити, що такий підхід потребує попередньої підготовки: інфраструктура має бути описана у вигляді Terraform-коду, а також сформовано набір YAML-конфігурацій для управління користувачами, їхніми доступами та правами. Саме це дозволяє автоматизувати зміни через GitOps і зробити їх відтворюваними.

Під час створення Merge Request автоматично призначається відповідальний за ревʼю та апрув змін. Одночасно Atlantis запускає terraform plan. Після перегляду змін і підтвердження з боку DevOps-команди виконується terraform apply, та зміни застосовуються до інфраструктури.

Таким чином, усі IAM-операції проходять через стандартний GitOps-контур із прозорим аудитом і контрольованим застосуванням змін.

Для GitLab-сценаріїв підхід інший: тут асистент використовує прямі API-виклики до GitLab для видачі, перевірки та відкликання доступів. Це швидше, простіше і краще відповідає самій природі GitLab-операцій.

Тобто ми не будували один універсальний IAM engine. Ми побудували єдиний Slack-інтерфейс для кількох різних механік, кожна з яких виявилася найбільш практичною для своєї системи.

AWS onboarding: там, де конфігурація важливіша за прямий API

Для AWS-інтеграції асистент працює з YAML-конфігураціями, де описані користувачі та їх членство в групах доступу. У спрощеному вигляді це виглядає так:

users:
  - username: oleksandr.shevchenko
    display_name: Oleksandr Shevchenko
    given_name: Oleksandr
    family_name: Shevchenko
    email: [email protected]

memberships:
  Administrator_Access:
    - oleksandr.shevchenko
  Analytics_RO:
    - iryna.kovalenko
  Developers_prod:
    - oleksandr.shevchenko

Коли хтось запускає AWS onboarding через Slack, асистент збирає Email, Username, Display name, Jira ticket та дає набір груп на вибір (Groups).

Асистент не створює AWS-користувача напряму. Його задача на цьому етапі інша — коректно оформити зміну конфігурації доступу і підготувати її до подальшого застосування.

Після того як Atlantis створює AWS-користувача, він викликає підписаний webhook у асистенті, передаючи username та email.

Асистент знаходить користувача в Slack за email, відкриває DM і відправляє повідомлення з параметрами для першого входу: логіном і посиланням на AWS SSO.

function buildMessage({ username, email }) {
  const lines = [];
  lines.push('Your AWS account is ready');
  lines.push('');
  lines.push(`Username: ${username}`);
  lines.push(`SSO: ${env.AWS_SSO_URL}`);
  lines.push('');
  lines.push('Please open the SSO link, sign in with the username above, and reset your password.');
  return lines.join('\n');
}

Далі користувач вже сам проходить стандартну первинну активацію, включно зі зміною стартового пароля та підключенням 2FA.

Тобто асистент не керує самим паролем і не виконує активацію за користувача. Він доводить запит до конфігураційної зміни, а потім коректно повідомляє людину, коли аккаунт вже створено.

Окремо ми реалізували сценарій перевірки прав користувача. Через Slack можна швидко знайти користувача за email і отримати його основні доступи та групи.

Це дозволяє оперативно перевіряти права без залучення DevOps і спрощує access review.

GitLab access flow: там, де API виявився природнішим

Для GitLab ми свідомо обрали інший шлях. Асистент працює безпосередньо через GitLab API.

У сценарії onboarding користувач у Slack вказує email, вибирає рівень доступу та список груп або проєктів. Асистент валідує введення, а потім через GitLab API надсилає запрошення до потрібних груп і проєктів. Після цього повертає результат у Slack-канал і, якщо операція успішна, додатково відправляє користувачу повідомлення в особисті повідомлення.

Це повідомлення надсилається користувачу якого додали.

Подібно побудовані й інші GitLab-сценарії. Перевірка доступів знаходить видимі memberships за @username, а оффбординг видаляє користувача з вибраних груп і проєктів також прямими API-викликами.

Окрім цього, у сценарії оффбордингу доступна можливість переглянути поточні доступи користувача та відредагувати їх перед застосуванням змін.

Це дозволяє видалити точково зайві доступи в межах одного workflow.

DB flow: конфігурації, права і видача credentials

Для інтеграції з базами даних підхід ближчий до AWS-сценарію. Асистент працює з YAML-файлами, де описані користувачі, інстанси, бази даних та grants. У спрощеному вигляді це виглядає так:

instance:
  prod:
    users:
      oleksandr.shevchenko:
        email: [email protected]
        access:
          prod: [SELECT]
  dev:
    users:
      natalia.bondarenko:
        email: [email protected]
        access:
          dev: [ALL PRIVILEGES]
          stage: [ALL PRIVILEGES]
  sandbox:
    users: {}

Онбординг, перевірка та оффбординг у цьому домені будуються навколо конфігураційного опису прав. Асистент або створює зміни та MR, або читає актуальний стан і повертає його в Slack.

Асистент надає (крила) на вибір Environment (грубо кажучи це аккаунт AWS) та запрошує заповнити додаткову інфо про користувача.

Далі обираємо інстанс (це RDS в якій крутяться бази), необхідну базу та grants.

Асистент формує МР.

Як відпрацював Atlantis, він викликає підписаний webhook у асистенті, передаючи username та email. Асистент знаходить користувача в Slack за email, відкриває DM і відправляє повідомлення (яке саме, подробиці в наступному розділі).

Це частина аутпуту від Atlantis.

Безпечна видача секретів через one-time link

Після створення юзера або resend-запиту асистент витягує секрет з AWS SSM Parameter Store (іnstance, host, port, username, password, databases, grants), створює одноразовий токен із TTL, зберігає payload у тимчасовому сховищі та формує посилання виду /secret/. Саме це посилання й іде користувачу в Slack DM.

      const dmText =
        `Credentials are ready for: ${parameterName}\n` +
        `Account: ${account}\n` +
        `One-time link (expires in ~${ttlMin} min): ${secretUrl}\n` +
        `If opened once, the link stops working.`;

Користувач може відкрити секрет лише один раз. Після першого перегляду токен інвалідється, а посилання стає недійсним.

Це дозволило залишити Slack зручним каналом комунікації, але не використовувати його як місце зберігання або повторної пересилки чутливих даних у відкритому вигляді.

Загальний flow:

LLM як другий інтерфейс

Коли основний workflow вже працював стабільно, ми додали ще один рівень взаємодії — LLM-інтерфейс поверх тих самих Slack-сценаріїв. Чесно кажучи, зробили Just for fun. Якоїсь загальної потреби не було.
Slash-команди та модальні форми залишилися основним і найбільш передбачуваним варіантом, але для тих, кому зручніше працювати в природному діалозі, з’явився ще один режим. У такому варіанті користувач може написати щось на кшталт «додай користувача [email protected] в AWS» або «перевір доступи в GitLab у ... », а асистент сам спробує визначити домен, дію та вже відомі параметри.

Далі йдемо в Тред.

При цьому LLM не виконує IAM-операції напряму. Вона працює як шар інтерпретації: допомагає зрозуміти намір користувача, уточнити відсутні поля і підготувати запит до звичного workflow. Для цього можна використовувати як зовнішню модель через OpenAI API, так і self-hosted варіант, наприклад Ollama в окремому контейнері поруч із асистентом (якщо залізо дозволяє).

Водночас модель не отримує повного доступу до секретів чи внутрішніх систем. У LLM передається лише мінімальний контекст, потрібний для інтерпретації поточного запиту: текст повідомлення, стан діалогу і вже зібрані поля. Уся робота з токенами, SSM, one-time secret delivery та реальними IAM-операціями залишається на боці самого застосунку.

Що змінилося після запуску

Після запуску асистента ефект став помітним досить швидко. Онбординг став значно більш передбачуваним і швидким: замість набору ручних кроків з’явилася зрозуміла точка входу в Slack і відтворювана обробка, яка зазвичай займає 10–20 хвилин разом із ревью.

Більшість сценаріїв без участі DevOps або IT. Зміни проходять через GitOps-контур або API, перевірка доступів виконується за секунди в Slack, а credentials більше не передаються у відкритому вигляді.

Не менш важливим був і організаційний ефект: навантаження на DevOps змістилося з ручних операцій до підтримки інтеграцій і процесу, а залежність від окремих людей значно зменшилась.

Що далі

Наступний етап розвитку ми бачимо не в повному переписуванні архітектури, а в послідовному посиленні вже працюючого контуру:

1. Покращення UX у Slack і скорочення кількості ручних полів та модалок.

2. Додавання пресетів grants в DB для більш системного підходу.

3. Розширення інтеграцій у тих доменах (Postman, Sentry, SonarQube ...), де ще залишаються ручні кроки.

4. Обережне використання LLM не заради магії, а для інтерпретації запитів і навігації по IAM-сценаріях.

Для нас IAM Assistant — це інфраструктурний шар, який робить операції з доступами зрозумілішими, відтворюваними й безпечнішими, не приховуючи реальної складності систем, з якими йому доводиться працювати.

Висновок

У результаті ми не просто автоматизували окремі дії, а формалізували роботу з доступами як процес: із чіткими правилами, перевірками, трейсінгом та повною прозорістю.