AWS

Кожен запит — це рішення про право

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

Думку можуть мати чотири речі, і встановлюють їх різні люди — саме це й робить налагодження заплутаним. Service control policy — це стеля, яку організація ставить над цілим акаунтом; вона може лише забирати, ніколи не надавати. Permission boundary — це стеля, яку адміністратор ставить на одну роль, щоб команда могла створювати ролі, не маючи змоги створити потужнішу за себе. Політика ідентичності прикріплена до користувача чи ролі, що питає. Політика ресурсу прикріплена до самої речі — бакета S3, черги, ключа — і саме вона взагалі дозволяє доступ ззовні акаунта. Явна заборона в будь-якій із них негайно завершує обчислення: ніщо нижче її не переважить.

Роль — це механізм, що робить усе це придатним до роботи, і його варто розуміти як окрему ідею, а не як «користувача для машин». Роль — це набір прав без власних облікових даних; принципал приймає її на себе й отримує облікові дані, що спливають за годину або швидше. Саме так застосунок на інстансі дістає доступ без того, щоб десь існував ключ; саме так один акаунт надає доступ іншому; і саме так людина дістає підвищене право на час задачі, а не назавжди. Майже будь-який дизайн доступу в AWS зводиться до двох питань: хто може прийняти яку роль і що ця роль дозволяє.

Акаунт — це радіус ураження

Новачки зазвичай вважають акаунт способом виставляти рахунки й намагаються розділяти середовища домовленостями про назви та тегами всередині одного. Це не тримається. Теги не спиняють скрипта, префікс у назві не спиняє права, а випадкове видалення у спільному акаунті дістає до всього, що бачив той, хто викликав. Акаунт — це жорстка межа: окремі ресурси, окремі типові ліміти, окремі облікові дані й жодної неявної довіри в обидва боки. Тож відповідь на питання «як уберегти прод від стейджингу» зазвичай — ще один акаунт, а створити його — це хвилини роботи.

Organizations — це шар, що робить багато акаунтів керованими, а не хаотичними. Акаунти лежать у дереві організаційних одиниць, рахунок консолідується нагорі, а service control policy застосовуються до одиниці й до всього під нею. Ці політики — єдиний механізм, що спиняє адміністратора акаунта, і саме тому це правильне місце для правил, які мають триматися незалежно від того, хто питає: жодних ресурсів поза дозволеними регіонами, жодного вимкнення журналювання аудиту, жодного видалення інструментів безпеки. Усе решта — хто що може робити щодня — належить самим акаунтам.

Географія — інша межа, і вона конкретніша, ніж здається. Регіон — це окремий набір дата-центрів із власною копією більшості сервісів; ресурс в одному регіоні не існує в іншому, і більшість сервісів регіональні, навіть коли консоль показує їх глобальними. Усередині регіону зона доступності — це незалежний домен збою з окремим живленням і мережею, і рознесення на дві-три зони — це те, що дає сервісу пережити проблему дата-центру. Тут же живе й цінова несподіванка: трафік між зонами тарифікується, часто в обидва боки, тож балакучий сервіс, рознесений по зонах заради стійкості, платить за цю стійкість погігабайтно.

Вибір серед двохсот сервісів

Каталог — це те, що людей приголомшує, і корисне спрощення таке: майже будь-яка робота існує на трьох рівнях абстракції. Можна орендувати машину й робити все самому; можна взяти керовану версію, де постачальник тримає операційну систему, латання, бекапи й перемикання при збої; або взяти безсерверну, де немає чого розмірювати взагалі, а платите ви за запит. Ті самі три рівні існують для обчислень, баз, черг і майже всього іншого, і рух угору драбиною міняє контроль і переносимість на експлуатаційну роботу, якої ви більше не робите.

Дві чесні засторови щодо цієї широти. Перша: AWS майже нічого не прибирає, тож каталог містить кілька поколінь тієї самої ідеї, а консоль радо запропонує вам найстаріше — перевіряйте, коли сервіс зʼявився і що його замінило, перш ніж брати. Друга: кількість сервісів не є підставою використовувати багато з них: кожен доданий — це модель прав, яку треба зрозуміти, режим збою, який треба вивчити, ліміт, у який упреться, і рядок у рахунку. Систему з шести добре зрозумілих сервісів експлуатувати легше, ніж із двадцяти ледь зрозумілих, — і саме її хтось зможе тримати, коли автор піде.

Як це виявляється в реальній поставці

Рахунок — це схема архітектури, якої ніхто не малював навмисне, і несподіванки зазвичай не в обчисленнях. Дані, що виходять із хмари, тарифікуються погігабайтно, і саме цей рядок перетворює функцію відео чи експорту на бізнесову проблему. Трафік між зонами доступності тарифікується, тож у стійкості є ціна за гігабайт. Керований шлюз трансляції адрес бере і погодинну ставку, і ставку за дані, — тому приватна підмережа, що говорить з інтернетом, може коштувати більше за інстанси в ній. А все, що виділили й забули — відʼєднаний диск, простійний балансувальник, зарезервована адреса, знімок після міграції, — тарифікується за повною ставкою, доки існує.

Дві звички не дають цьому перетворитися на щорічну паніку. Тегуйте все власником і призначенням із першого ж ресурсу, бо тег, доданий пізніше, ніколи не покриває того, що існувало до нього, а нетегований рахунок нікому не приписати. І створюйте ресурси з коду — репозиторій, перегляд, застосування конвеєром, — а не з консолі. Консоль — правильне місце, щоб дивитися на речі, і хибне, щоб їх робити: ресурс, створений клацанням, не має історії, не відтворюється в іншому акаунті й невидимий для наступної людини, доки не зʼявиться в рахунку.

Нарешті, знайте, де закінчується відповідальність постачальника. AWS тримає залізо, гіпервізор, фізичну безпеку й нутрощі керованого сервісу; ви володієте конфігурацією, правами, латанням усього, що встановили, і передусім своїми даними. Кожен гучний «хмарний злам» останнього десятиліття був на клієнтському боці цієї межі: бакет, лишений публічним, закомічений ключ, роль із більшими правами, ніж їй було треба. Постачальник не врятує вас від політики, яку написали ви, а типові налаштування — це відправна точка, а не стан безпеки.

Де це вироджується

• Один акаунт на всі середовища, розділені домовленостями про назви, які не спиняють нічого.
• Довгоживучі ключі доступу в CI, на ноутбуках і в репозиторіях замість прийнятих ролей.
• Політика із зірочкою, написана, щоб розблокувати першу годину, і ніколи потім не звужена.
• Журнали аудиту, записані в той самий акаунт, що й навантаження, яке вони мають аудитувати.
• Ресурси, створені в консолі: нічого не переглянути, не відтворити й не пояснити.
• Нетеговані ресурси: рахунок нікому не приписати, і прибирання не має власника.
• Балакучий сервіс, рознесений по зонах доступності, платить погігабайтно за власну балаканину.
• Сервіс старого покоління, взятий тому, що консоль запропонувала його першим.
• Двадцять сервісів там, де витягли б шість, і в кожного власний режим збою.

Коли це застосовувати

Пов’язані сторінки

• ІнфраструктураGCPGoogle Cloud (GCP) побудований навколо ієрархії, що успадковується: організація містить теки, теки містять проєкти, а проєкт містить усе решта. Це звучить адміністративно й водночас є найважливішою річчю на платформі, бо проєкт достатньо дешевий, щоб створити його під один сервіс, і достатньо цілісний, щоб видалити однією дією. На цій сторінці — ієрархія і що нею успадковується, чому сервісні акаунти є звичайним шляхом усередину, мережева модель, що різниться від усіх інших, і де платформа справді сильна, а де справді ні.
• ІнфраструктураAzureAzure — це хмара Microsoft, і перше, що варто про неї знати: у ній дві системи керування, які сприймають як одну, а вони не одна. Каталог тримає ідентичності й існував задовго до хмари — це той самий каталог, що стоїть за корпоративною поштою й входом у систему. Окремий ресурсний план тримає підписки, групи ресурсів і все, що ви розгортаєте. Бути адміністратором першого не дає нічого в другому. На цій сторінці — цей поділ і чому він спричиняє плутанину першого дня, ланцюг областей, яким успадковуються права, де Azure справді є правильною відповіддю і чого платформа коштує вам у мінливості назв.
• ІнфраструктураKubernetesKubernetes — це цикл керування з API перед ним. Ви не наказуєте йому запустити контейнер: ви записуєте бажаний стан, а контролери постійно звіряють цей запис із тим, що працює насправді, і діють на різницю — завжди, а не один раз. Кожен обʼєкт, який він пропонує, і кожна його несподівана поведінка походять звідси. На цій сторінці — сам цикл, кілька обʼєктів, що справді важать, чому ліміти ресурсів і перевірки здоровʼя спричиняють більшість інцидентів у проді й коли все це вам справді потрібне.