По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
На данный момент Kubernetes является одной из самых интересных технологий в мире DevOps. В последнее время вокруг него образовалось очень много хайпа, по одной простой причине, и причина эта – всемогущие контейнеры.
Компания Docker Inc. привлекла народное внимание к контейнерам с помощью маркетинговых компаний о своем прекрасном продукте (у нас есть статья о первоначальной настройке Docker). Но что интересно, Docker – не первопроходец в мире контейнеров, но они положили начало их победоносному походу по миру. Что же было в начале? А в начале были Linux контейнеры, внимание к которым также возросло после такого ажиотажа вокруг Docker контейнеров, при этом и повысив потребность к контейнерным оркестраторам.
Давайте поближе познакомимся с Кормчим – он же Kubernetes. Первоначально это являлось разработкой Google, для управления их гигантской инфраструктурой, состоящей из миллионов контейнеров. В какой-то момент Google отдал Кормчего в люди, а именно - Cloud Native Computing Foundation. На данный момент, Docker добавил Kubernetes в свои сборки как один из вариантов оркестраторов наравне с Docker Swarm.
Теперь Kubernetes также будет частью сборок Docker Community и Docker Enterprise Edition.
Общий обзор Кормчего
Пожалуй, тут нужно разъяснить: Kubernetes является греческим именем кормчего или управляющего кораблём
В зарубежных коммьюнити Кормчий носит несколько названий – Kubernetes, k8s или kube и является платформой с открытым кодом. Данная платформа позволяет автоматизировать операции с контейнерами – запуск, масштабирование, управление контейнизированными приложениями и так далее. Kubernetes может помочь вам сохранить десятки часов жизни и бесценного времени.
Kubernetes позволяет вам помещать в кластер группы хостов с контейнерами и управлять этими кластерами. Эти кластеры могут работать в публичных, частных и гибридных облаках – может, однажды, даже в Хогвартсе откажутся от сложных заклинаний в пользу Kubernetesа.
Как я уже упомянул, Kubernetes изначально является разработкой Google, но будет также нелишним знать, что Kubernetes включен во многие облачные коммерческие предложения Корпорации Добра.
Сам Google запускает более чем 2 миллиарда контейнеров в неделю. Это почти 300 миллионов контейнеров в день с помощью своей внутренней платформы Borg. Эта платформа – предшественник Kubernetes. Все ошибки Borg были учтены и исправлены в Кормчем./
Использование Kubernetes позволяет получать радость от управления и запуска контейнизированных приложений – он автоматизирует запуск и откаты сборок, мониторит запущенные сервисы – т.е вы можете узнать о том, что что-то пойдет не так еще до непосредственной инициации процесса.
Кроме того, Kubernetes управляет ресурсами и может масштабировать необходимые ресурсы для приложений в зависимости от того, сколько им требуется, для того, чтобы избежать лишней траты ресурсов.
Как работает Kubernetes?
Посмотрите на схему с официального сайта (ссылка ниже):
Как вы видите, Kubernetes это очень сложная система (особенно если сравнивать с нативным оркестратором Docker Swarm). Чтобы понять, как он работает, необходимо сначала понять его базовые принципы.
Желаемое состояние
Желаемое состоятие (Desired state) – это один из базовых концептов Kubernetes. Вы можете указать необходимое состояние для запуска контейнеров в т.н Подах. То есть, к примеру, если контейнер почему-то перестал работать, Kubernetes заново создаст Под основываясь на указанном желаемом состоянии.
Kubernetes всегда проверяет состояние контейнеров в кластере, и этим занимается т.н Kubernetes Мастер, который является частью плоскости управления. Можно использовать объект kubectl – он напрямую взаимодействует с кластером для установки или изменения Desired State через Kubernetes API.
Объекты Kubernetes
Обратимся к официальной документации Kubernetes: объект в Kubernetes это «запись о намерениях» (record of intent) – после создания объекта, Kubernetes будет постоянно проверять наличие этого объекта. При создании объекта, вы сообщаете Кормчему как должна выглядеть загрузка вашего кластера, иначе говоря – каково его желаемое состояние.
Состояние сущностей в системе в любой взятый момент времени представлено Kubernetes объектами. Кроме того, объекты также служат как дополнительный уровень абстракции над интерфейсом контейнеров. Вы можете напрямую взаимодействовать с сущностями объектов вместо взаимодействия с контейнерами. Ниже приведем список базовых объектов в Kubernetes.
Под (Pod) – наименьшая запускаемая единица в ноде. Это группа контейнеров, которые должны работать вместе. Довольно часто (но не всегда) в поде находится только один контейнер;
Сервис(Service) – данный объект используется для обозначения логической суммы подов и политик, используемых для доступа к подам;
Раздел (Volume) – директория, которая доступна всем контейнерам внутри пода;
Именные пространства (Namespaces) – виртуальные кластеры, поддерживаемые физическим кластером;
Также в Kubernetes есть несколько контроллеров, которые построены на базовых объектах и они предоставляют дополнительные фичи. Ниже список данных контроллеров:
ReplicaSet - проверяет что какое-то количество копий подов также все время запущено;
Deployment - используется для смены текущего состояния на желаемое состояние;
StatefulSet - используется для контроля над развертыванием и доступов к разделам;
DaemonSet - используется для копирования пода на все ноды кластера или только на указанные ноды;
Job - используется для реализации какой-то задачи и прекращения существования после завершения задачи или после указанного времени
Плоскость управления в Kubernetes
Плоскость управления в Kubernetes используется для установки кластера в желаемое состояние, и для этого Kubernetes выполняет множество задач автоматически – старт и перезагрузка контейнеров, изменение количества реплик приложения и так далее.
Различные части плоскости управления, такие как Kubernetes Мастер и процесс kubelet задают тон тому, как Kubernetes взаимодействует с вашим кластером. Плоскость управления содержит записи о всех объектах Kubernetes в системе и запускает бесконечные петли управления для контроля состояния объектов. В каждый момент времени эти петли будут реагировать на изменения в кластере и будет приводить состояние всех объектов в системе из текущего состояния в желаемое. Представьте себе правительство страны, которое проверяет все ли работают и существуют в соответствии с законом.
Kubernetes Мастер являются частью плоскости управления, и выполняет такую же задачу по сохранению желаемого состояния во всем вашем кластере. Команда kubectl является интерфейсом для взаимодействия с мастером в кластере через API.
В документации написано: «мастер» - это группа процессов, управляющих состоянием кластера. Как правило, все эти процессы запущены одной ноде в кластере и эта нода также называется мастер-нодой. Мастер-нода также может быть реплицирована для избыточности и отказоустойчивости.
Каждый мастер в кластере являет собой совокупность следующих процессов:
kube-apiserver - единственная точка управления для целого кластера. Команда cubectl взаимодействует напрямую через API;
kube-controller-manager - управляет состоянием кластера, управляя различными контроллерами;
kube-scheduler - планирует задачи на всех доступных нодах в кластере;
Ноды в Kubernetes
Ноды в Kubernetes – это ваши «сервера» - виртуалки, физические и так далее, которые находятся в кластере и на которых запущены ваши приложения. Ноды также контролируются мастером и постоянно мониторятся для того, чтобы устанавливать желаемое состояние для приложений. Раньше они назывались «миньонами» - но не теми желтыми милахами из мультика. Каждая нода в кластере держит два процесса:
kubelet– интерфейс между нодой и мастером;
kube-proxy – сетевая прокси, через которую проходят сервисы, указанные в API на каждой ноде. Также эта прокси может совершать простой TCP и UDP проброс портов;
Установка Kubernetes
Теперь давайте посмотрим как это работает. Для этого необходимо установить Kubernetes у вас на сервере. Нужно скачать и установить Docker Community Edition версий 17.12.+ и затем для локального запуска нужно установить Minikube.
Ссылка для скачивания Docker Community Edition - здесь;
Ссылка для скачивания Minikube - тут (MiniKube)
При использовании Minikube надо помнить, что создается локальная виртуальная машина и запускает кластер, состоящий из одной ноды. Но ни в коем случае не используйте его для продакшена – Minikube служит исключительно для тестирования и разработки.
Для запуска однонодного кластера достаточно лишь выполнить команду minikube start. Бадумс, вы одновременно запустили виртуальную машину, кластер и сам Kubernetes.
$minikube start
Starting local Kubernetes v1.10.0 cluster...
Starting VM...
Getting VM IP address...
Moving files into cluster...
Setting up certs...
Connecting to cluster...
Setting up kubeconfig...
Starting cluster components...
Kubectl is now configured to use the cluster.
Loading cached images from config file.
Для проверки установки надо ввести команду kubectl version
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.1", GitCommit:"3a1c9449a956b6026f075fa3134ff92f7d55f812", GitTreeState:"clean", BuildDate:"2018-01-04T20:00:41Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.0", GitCommit:"fc32d2f3698e36b93322a3465f63a14e9f0eaead", GitTreeState:"clean", BuildDate:"2018-03-26T16:44:10Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
Git – это популярная система контроля версий. Благодаря Git разработчики могут сотрудничать и без проблем работать над проектами совместно.
Git позволяет отслеживать изменения, которые вы вносите в проект с течением времени. Помимо этого, он позволяет вернуться к предыдущей версии, если вы вдруг решили не вносить изменение.
Git работает по следующему принципу: вы размещаете файлы в проекте с помощью команды git add, а затем фиксируете (коммитите) их с помощью команды git commit.
При совместной работе над проектами могут возникнуть ситуации, когда вы не захотите, чтобы какие-то файлы или части проекта были видны всем участникам команды.
Иными словами, вы не захотите включать и фиксировать эти файлы в основной версии проекта. Вот почему вы можете не захотеть использовать разделитель (точку) с командой git add, так как в этом случае каждый отдельный файл будет размещен в текущем каталоге Git.
Когда вы используете команду git commit, то каждый отдельный файл фиксируется – это также добавляет файлы, которые не нужно.
Вы можете, наоборот, захотеть, чтобы Git игнорировал определенные файлы, но для такой цели не существует команды git ignore.
Итак, как же сделать так, чтобы Git игнорировал и не отслеживал определенные файлы? С помощью файла .gitignore.
В этой статье вы узнаете, что такое файл .gitignore, как его создать и как использовать для игнорирования некоторых файлов и папок. Также вы узнаете, как можно заставить Git игнорировать уже закоммиченый файл.
Что такое файл .gitignore? Для чего он нужен?
Каждый из файлов в любом текущем рабочем репозитории Git относится к одному из трех типов:
Отслеживаемые – это все файлы и каталоги, о которых знает Git. Это файлы и каталоги, которые были недавно размещены (добавлены с помощью git add) и зафиксированы (закоммичены с помощью git commit) в главном репозитории.
Неотслеживаемые – это новые файлы и каталоги, которые созданы в рабочем каталоге, но еще не размещены (или добавлены с помощью команды git add).
Игнорируемые – это все файлы и каталоги, которые полностью исключаются и игнорируются, и никто о них в репозитории Git не знает. По сути, это способ сообщить Git о том, какие неотслеживаемые файлы так и должны остаться неотслеживаемыми и не должны фиксироваться.
Все файлы, которые должны быть проигнорированы, сохраняются в файле .gitignore.
Файл .gitignore – это обычный текстовый файл, который содержит список всех указанных файлов и папок проекта, которые Git должен игнорировать и не отслеживать.
Внутри файла .gitignore вы можете указать Git игнорировать только один файл или одну папку, указав имя или шаблон этого конкретного файла или папки. Используя такой же подход, вы можете указать Git игнорировать несколько файлов или папок.
Как создать файл .gitignore
Обычно файл .gitignore помещается в корневой каталог репозитория. Корневой каталог также известен как родительский или текущий рабочий каталог. Корневая папка содержит все файлы и другие папки, из которых состоит проект.
Тем не менее, вы можете поместить этот файл в любую папку в репозитории. Если на то пошло, но у вас может быть несколько файлов .gitignore.
Для того, чтобы создать файл .gitignore в Unix-подобной системе, такой как macOS или Linux, с помощью командной строки, откройте приложение терминала (например, в macOS это Terminal.app). Затем для того, чтобы создать файл .gitignore для вашего каталога, перейдите в корневую папку, которая содержит проект, и при помощи команды cd введите следующую команду:
touch .gitignore
Файлы, перед именем которых стоит точка ., по умолчанию скрыты.
Скрытые файлы нельзя просмотреть, используя только команду ls. для того, чтобы иметь возможность просмотреть все файлы, включая скрытые, используйте флаг -a с командой ls следующим образом:
ls –a
Что добавлять в файл .gitignore
В файл .gitignore должны быть добавлены файлы любого типа, которые не нужно фиксировать.
Вы можете не хотеть их фиксировать из соображений безопасности или потому, что они нужны только вам и не нужны другим разработчикам, работающим над тем же проектом, что и вы.
Вот некоторые файлы, которые могут быть включены:
Файлы операционной системы. Каждая операционная система, будь то macOS, Windows или Linux, создает системные скрытые файлы, которые не нужны другим разработчикам, так как их система создает такие же файлы. Например, в macOS Finder создает файл .DS_Store, который содержит пользовательские настройки внешнего вида и отображения папок, такие как размер и положение иконок.
Файлы конфигурации, создаваемые такими приложениями, как редакторы кода и IDE (Integrated Development Environment – интегрированная среда разработки). Эти файлы настроены под вас, ваши конфигурации и ваши настройки, например папка .idea.
Файлы, которые автоматически генерируются языком программирования или средой разработки, которую вы используете для своего проекта, и в процессе компиляции специфичных для кода файлов, такие как файлы .o.
Папки, созданные диспетчерами пакетов, например, папка npm node_modules. Это папка, которая используется для сохранения и отслеживания зависимостей для каждого пакета, который вы устанавливаете локально.
Файлы, которые содержат конфиденциальные данные и личную информацию. Примерами таких файлов могут послужить файлы с вашими учетными данными (имя пользователя и пароль) и файлы с переменными среды, такие как файлы .env (файлы .env содержат ключи API, которые должны оставаться защищенными и закрытыми).
Файлы среды выполнения, такие как файлы .log. Они предоставляют информацию об использовании операционной системы и ошибках, а также историю событий, произошедших в рамках ОС.
Как игнорировать файл или папку в Git
Если вы хотите игнорировать только один конкретный файл, то вам необходимо указать полный путь к файлу из корневой папки проекта.
Например, если вы хотите игнорировать файл text.txt, который расположен в корневом каталоге, то вы должны сделать следующее:
/text.txt
А если вы хотите игнорировать файл text.txt, который расположен в папке test корневого каталоге, вы должны сделать следующее:
/test/text.txt
Вы можете это записать иначе:
test/text.txt
Если вы хотите игнорировать все файлы с определенным именем, то вам нужно написать точное имя файла.
Например, если вы хотите игнорировать любые файлы text.txt, то вы должны добавить в .gitignore следующее:
text.txt
В таком случае вам не нужно указывать полный путь к конкретному файлу. Этот шаблон будет игнорировать все файлы с таким именем, расположенные в любой папке проекта.
Для того, чтобы игнорировать весь каталог со всем его содержимым, вам нужно указать имя каталога со слешем в конце:
test/
Эта команда позволит игнорировать любой каталог (включая другие файлы и другие подкаталоги внутри каталога) с именем test, расположенный в любой папке вашего проекта.
Стоит отметить, что если вы напишете просто имя каталога без слеша, то этот шаблон будет соответствовать как любым файлам, так и любым каталогам с таким именем:
# соответствует любым файлам и каталогам с именем test
test
Что делать, если вы хотите игнорировать любые файлы и каталоги, которые начинаются с определенного слова?
Допустим, вы хотите игнорировать все файлы и каталоги, имя которых начинается с img. Для этого вам необходимо указать имя, а затем селектор подстановочного символа *:
img*
Эта команда позволит игнорировать все файлы и каталоги, имя которых начинается с img.
Но что делать, если вы хотите игнорировать любые файлы и каталоги, которые заканчиваются определенным набором символов?
Если вы хотите игнорировать все файлы с определенным расширением, то вам необходимо будет использовать селектор подстановочного знака *, за которым последует расширение файла.
Например, если вы хотите игнорировать все файлы разметки, которые заканчиваются расширением .md, то вы должны в файл .gitignore добавить следующее:
*.md
Этот шаблон будет соответствовать любому файлу с расширением .md, расположенному в любой папке проекта.
Мы разобрали, как игнорировать все файлы, которые оканчиваются одинаково. Но что делать, если вы хотите сделать исключение для одного из этих файлов?
Допустим, вы добавили в свой файл .gitignore следующее:
.md
Этот шаблон позволит игнорировать все файлы, оканчивающиеся на .md, но вы, например, не хотите, чтобы Git игнорировал файл README.md.
Для этого вам нужно будет воспользоваться шаблоном с отрицанием (с восклицательным знаком), чтобы исключить файл, который в противном случае был бы проигнорирован, как и все остальные:
# игнорирует все файлы .md
.md
# не игнорирует файл README.md
!README.md
Учитывая эти два шаблона в файле .gitignore, все файлы, оканчивающиеся на .md будут игнорироваться, кроме файла README.md.
Стоит отметить, что данный шаблон не будет работать, если вы игнорируете весь каталог.
Допустим, что вы игнорируете все каталоги test:
test/
И допустим, внутри папки test у вас есть файл example.md, который вы не хотите игнорировать.
В этом случае вы не сможете сделать исключение для файла внутри игнорируемого каталога следующим образом:
# игнорировать все каталоги с именем test
test/
# попытка отрицания файла внутри игнорируемого каталога не сработает
!test/example.md
Как игнорировать ранее закоммиченый файл
Лучше всего создать файл .gitignore со всеми файлами и различными шаблонами файлов, которые вы хотите игнорировать, при создании нового репозитория, до его коммита.
Git может игнорировать только неотслеживаемые файлы, которые еще не были зафиксированы в репозитории.
Что же делать, если вы уже закоммитили файл, но хотели бы, чтобы он все-таки не был закоммичен?
Допустим, что вы случайно закоммитили файл .env, в котором хранятся переменные среды.
Для начала вам необходимо обновить файл .gitignore, чтобы включить файл .env:
# добавить файл .env в .gitignore
echo ".env" >> .gitignore
Теперь, вам нужно указать Git не отслеживать этот файл, удалив его из перечня:
git rm --cached .env
Команда git rm вместе с параметром --cached удаляет файл из репозитория, но не фактический файл. Это значит, что файл остается в вашей локальной системе и в вашем рабочем каталоге в качестве файла, который игнорируется.
Команда git status покажет, что файла в репозитории больше нет, в ввод команды ls покажет, что файл существует в вашей локальной файловой системе.
Если вы хотите удалить файл из репозитория и вашей локальной системы, то не используйте параметр --cached.
Затем добавьте .gitignore в область подготовленных файлов с помощью команды git add:
git add .gitignore
И наконец, закоммитте файл .gitignore с помощью команды git commit:
git commit -m "update ignored files"
Заключение
Вот и все – теперь вы знаете, как игнорировать файлы и папки в Git.
В начале пути веб-разработки вы, скорее всего, часто будете слышать такие понятия, как аутентификация (authentication) и авторизация (authorization). И здесь не сильно помогает тот факт, что они оба обычно сокращаются до «auth», и их легко перепутать.
Из этой статьи вы узнаете:
о различиях между аутентификацией и авторизацией
о том, как работают эти процессы
примеры авторизации и аутентификации из реальной повседневной жизни
Итак, давайте начнем!
Что такое аутентификация?
Аутентификация – это процесс проверки учетных данных, которые предоставляет пользователь, с теми, что хранятся в системе, с целью подтверждения того факта, что пользователь является тем, за кого себя выдает. Если учетные данные совпадают, вы предоставляете пользователю доступ, если нет – то доступ для пользователя запрещается.
Методы аутентификации
Однофакторная аутентификация
Такой метод аутентификация обычно используется в системах с низким уровнем риска. Для этого метода требуется всего один фактор; чаще всего это пароль. Именно поэтому системы с однофакторной аутентификацией наиболее уязвимы для фишинговых атак и клавиатурных шпионов.
Плюс ко всему, в недавно опубликованной сайтом DataProt статье было продемонстрировано, что 78% представителей поколения Z используют один и тот же пароль для нескольких сервисов. А это значит, что, если злоумышленник получит доступ к одной учетной записи пользователя, то с большей долей вероятности он получит доступ и к другим с помощью того же пароля.
Двухфакторная аутентификация
Метод двухфакторной аутентификации является более безопасным, поскольку он включает в себя два фактора; обычно это то, что вы знаете, например, имя пользователя и пароль, и что-то, что у вас есть или чем вы владеете, например, SMS, отправленное на ваш телефон, или маркер доступа.
Для двухфакторной аутентификации вам потребуется ввести одноразовый пароль, который был отправлен в SMS-сообщении на ваш телефон, или, возможно, код привязанного приложения-аутентификатора и предоставить код доступа, который постоянно меняется.
Как вы уже могли понять, это намного безопаснее, чем просто ввести пароль или учетные данные для аутентификации. Для того, чтобы получить доступ, вам необходимо будет не только знать учетные данные для входа в систему, но и иметь доступ к физическому устройству.
За последние несколько лет двухфакторная аутентификация стала достаточно распространенной среди различных онлайн-сервисов, а многие крупные компании используют этот метод в качестве стандартного метода аутентификации. В некоторых случаях обязательным требованием использования сервиса является настройка двухфакторной аутентификации.
Многофакторная аутентификация
Если вы хотите пойти дальше и сделать процесс аутентификации еще более безопасным, то можете использовать три и более факторов. Такой формат аутентификации, как правило, работает по следующей схеме:
то, что вы знаете (имя пользователя + пароль или имя пользователя + пароль + контрольный вопрос и ответ)
то, что у вас есть (SMS, отправленное на ваш телефон, приложение-аутентификатор, USB-ключ)
то, чем вы являетесь (отпечаток пальца, распознавание лица)
Именно поэтому многофакторная аутентификация обеспечивает наибольшую защиту, поскольку для получения доступа необходимо предоставить несколько факторов, а их не так просто «взломать» или воспроизвести.
Есть у этого метода один недостаток, он же причина, по которой многофакторная аутентификация не используется в среднестатистических системах – этот метод может оказаться слишком трудным в настройке и обслуживании. И поэтому данные или система, которую вы защищаете таким образом, должны полностью оправдывать необходимость использования такой системы безопасности.
Итак, а сколько информации необходимо для аутентификации?
Этот вопрос часто поднимается на многих совещаниях по архитектуре безопасности. И ответ на него следующий: «это зависит от…».
Компании часто совмещают несколько различных методов аутентификации в зависимости от специфики приложения для того, чтобы повысить уровень безопасности.
Возьмем, к примеру, банковское приложение. Оно содержит конфиденциальную информацию, и если она попадет не в те руки, то банку это грозит последствиями, которые отразятся на финансовой части и на репутации банка. Банк может совмещать вопросы личного характера, на которые пользователю необходимо ответить, с номером клиента и надежным паролем.
В случае с социальными сетями вам могут потребоваться лишь имя пользователя и пароль, которые проверяются и подтверждаются, после чего пользователю разрешается доступ.
Все упирается в уровень риска и в то, кто к какой информации может получить доступ, находясь в приложении. Это позволяет определить уровень аутентификации, который вам нужен.
Если вы или ваша команда неверно оцените, а именно недооцените, необходимый для вашего приложения уровень аутентификации, то вас могут привлечь к ответственности за недостаточную защиту данных в вашей системе. Именно поэтому компании нанимают специалистов по безопасности, чтобы они проконсультировали их по передовым методам и нашли подходящие решение.
Как работает аутентификация в реальной жизни?
Для примера возьмем аккаунт в социальной сети. Вы выбираете социальную сеть (сайт размещен на сервере), которую вы больше предпочитаете. Сервер потребует предоставить учетные данные для доступа к сайту через страницу входа в систему. Здесь вы должны ввести свое имя пользователя и пароль, которые были использованы для создания учетной записи.
Иллюстрация процесса аутентификации
После чего эти данные отправляются на сервер, и начинается процесс аутентификации. Данные, которые вы предоставили, проверяются в базе данных сервера, и в случае, если они совпадают с данными в записи, вы проходите процесс аутентификации. Затем вам предоставляется форма данных, подтверждающих личность, например, cookie-файл или веб-токен JSON (JWT – JSON Web Token).
Отлично! Вы получили доступ к сайту и вошли в учетную запись.
Теперь рассмотрим процесс авторизации.
Что такое авторизация?
Авторизация – это процесс проверки того, что вам разрешен доступ к определенной области приложения или что вы можете выполнять определенные действия на основании определенных критериев или условий, которые были установлены приложением. Также этот процесс называют «управлением доступом» или «управлением привилегиями».
Авторизация может как предоставить право на выполнение неких задач или на доступ к определенным областям приложения, так и не дать его.
Давайте рассмотрим на примере:
Мы уже получили доступ к социальной сети, но то, что мы можем там делать, зависит от того, какие у нас есть полномочия.
Если мы попробуем получить доступ к чьему-либо профилю, с которым мы не «дружим» (владелец профиля не принял запрос на «дружбу»), то мы не сможем просмотреть его – у нас не будет на это права. Это значит, что нам отказано в доступе к публикациям, которые сделал владельц этого профиля.
Процесс авторизации
Как реализовать авторизацию
В зависимости от фреймворков, которые вы используете, есть большое количество способов, как можно реализовать авторизацию.
Например, на платформе .NET вы можете использовать ролевое управление доступом или управление доступом на основе утверждений.
Ролевое управление доступом в своей основе имеет идеологию, которая подразумевает, что каждому пользователю в вашей системе назначается какая-то определенная роль. Эти роли имеют заранее определенные права доступа для каждого пользователя. Пользователь, которому была предоставлена та или иная роль, автоматически получает эти права доступа. Роли назначаются в процессе создания и настройки пользователя.
Затем, когда пользователь попытается получить доступ, например, к области администрирования, конечная точка или сайт просто проверят, имеет ли текущий пользователь роль администратора.
Недостаток данного подхода заключается в том, что иногда пользователям предоставляются слишком много прав доступа, некоторые из которых им не нужны или не должны были быть им предоставлены.
Например, если пользователю предоставили роль администратора (Admin), то это значит, что у него есть право доступа пользователя на комплексное создание (Advanced Create), редактирование (Edit), удаление (Delete) и просмотр (View). В то время как вы можете предоставить им право только на просмотр (View) и первичное создание (Basic Create).
Управление доступом на основе утверждений позволяет выполнить более точную настройку прав доступа конкретного пользователя. Приложение может проверить, закреплено ли за пользователем утверждение или присвоено ли утверждению конкретное значение.
Например, пользователю может быть передано утверждение CreateUser; оно проверяется при создании пользователя. Или вы можете присвоить тому же утверждению значение Advanced, а затем получить доступ к различным действиям и пользовательскому интерфейсу в зависимости от того, присвоили вы значение Advanced или Basic.
В чем разница между аутентификацией и авторизацией?
Итак, теперь, когда мы рассмотрели оба термина и разобрались в том, что они означают, давайте взглянем на сценарий, с которым, я думаю, многие знакомы и который включает в себя оба процесса.
На званом ужине с особым списком гостей каждому гостю присваивается имя и секретный пароль.
По прибытии сотрудник охраны спрашивает у вас ваше имя и секретный пароль. Далее они аутентифицируют ваши учетные данные по списку, который у них имеется. Если ваши учетные данные совпадают, то вам вручают конверт, который показывает, что вас допустили.
Оказавшись внутри, у вас есть право получить доступ к званому ужину и общим зонам заведения, поскольку для них авторизация не требуется (у всех есть право быть допущенным до званого ужина). Однако после вы захотите посетить VIP-зону.
Когда вы подходите к ней, то другой сотрудник охраны просит открыть конверт, который вам вручили (в нем описаны ваши права доступа и роли). Он смотрит, но, к сожалению, у вас нет роли VIP, и поэтому вы не можете быть авторизованы. Если простыми словами, то аутентификация проверяет личность пользователя или службы, разрешающей доступ, а авторизация определяет, что они могут делать, после того, как окажутся внутри.
Почему следует реализовать как аутентификацию, так и авторизацию?
Как вы могли заметить, несмотря на то, что аутентификация и авторизация сами по себе очень разные, каждый из этих процессов играет свою неотъемлемую роль в обеспечении безопасности и целостности приложения или системы.
Эти процессы действуют заодно, и один без другого не имеет смысла. Если вы можете получить доступ к области администрирования и при этом делать там все, что вам вздумается, то это может привести к серьезным проблемам.
А с другой стороны, вы не сможете авторизовать людей, не зная, кто они! Именно поэтому аутентификация всегда идет до авторизации.
Заключение
Я надеюсь, что данная статья оказалась полезной, и теперь вы знаете, чем авторизация отличается от аутентификации и как их использовать.
И запомните:
Аутентификация = проверяет личность пользователя или процесса
Авторизация = определяет, есть ли у пользователя/системы права доступа на использование какого-либо ресурса или выполнения какого-либо действия.