В предыдущем посте ArgoCD: пользователи, доступы и RBAC разобрались с пользователями и RBAC в целом, теперь настроим ArgoCD SSO. Идея заключается в том, что мы не заводим локальных пользователей в ArgoCD, а используем базу Okta, и она же выполняет их аутентификацию. На стороне же ArgoCD мы будем выполнять авторизацию, т.е. проверять уровни доступа. Плюс, используя… Читать далее »
ArgoCD использует два типа пользователей — локальные, заданные в argocd-cm ConfigMap, и SSO. Ниже рассмотрим работу с локальными пользователями, а позже добавим SSO и группы, так как для локальных пользователей нельзя создавать группы, см. Local users/accounts. Разделение доступов выполняется с помощью ролей, которым подключаются политики, описывающие к чему есть доступ, и на какие операции. При… Читать далее »
Для аутентицикации и авторизации в Kubernetes имеются такие понятия как User Accounts и Service Accounts. User Accounts — профили обычных пользователей, используемые для доступа к клатеру снаружи кластера, тогда как Service Accounts используются для аутентификации сервисов внутри кластера. ServiceAccounts предназначены для предоставления идентификатора, используя который Kubernetes Pod, а точнее контейнер(ы) в нём, могут быть… Читать далее »
В продолжение поста Helm: пошаговое создание чарта и деплоймента из Jenkins — теперь нам надо добавить шифрование данных, что бы не хранить пароли и различные приватные ключи в открытом виде в Github-репозиториях — даже пусть и приватных. Судя по гуглу, чуть ли не единственный вариант — это использование helm-secrets (а подскажите в комментариях — кто… Читать далее »
Задача — создать пользователя, у которого будет возможность проверять состояние подов и читать их логи — ко всем другим операциям доступа быть не должно. AWS EKS использует AWS IAM для аутентификации в в Kubernetes-кластере (см. пост Kubernetes: знакомство, часть 4 — аутентификация в AWS EKS, aws-iam-authenticator и AWS IAM), но для авторизации, т.е. определения конкретных… Читать далее »
Сейчас у меня KeePass используется как менеджер паролей, хранилище RSA-ключей и в роли Freedesktop SecretService, см. пост KeePass: настройка MFA, хранение паролей браузера, паролей SSH ключей и интеграция Secret Service. Первая проблема применения KeePass в роли SecretService заключается в том, что у меня его база синхронизируется между компьютерами (просто хранится в Dropbox), и он каждый… Читать далее »
Итак, наверно уже завершающая часть всего этого мерлезонского балета. Предыдущие части, с которых «всё начиналось»: Linux: Nextcloud клиент, qtkeychain и ошибка «The name org.freedesktop.secrets was not provided by any .service files» — увидел, что в keyring сервисе можно хранить пароли от SSH ключей — узнал, что Chromium хранит пароли «незашифрованными» Linux: KeePass, SSH и хранение… Читать далее »
Одним из поводов настолько углубиться в keyrings (см. What is: Linux keyring, gnome-keyring, Secret Service, и D-Bus) был факт того, что Chromium, внезапно, при отсутствии keyring в Linux будет хранить пароли в «открытом виде». Собственно, давайте попробуем найти — как и где Chromium хранит пароли, и, самое важное — шифрует ли он их? Chromium и… Читать далее »
Очень длиннопост получился. Я долго думал — собирать ли всё в одном посте, или всё-таки разбить на несколько, ведь с одной стороны keyrings — это одна тема, D-Bus — другая, а примеры работы с SecretServices — вообще третья. Тем не менее — решил всё-таки оставить в одном, так как со всем этим разбирался по ходу… Читать далее »
Одной из больших проблем при использовании MFA является вопрос с доступом к общим почтовым ящикам. Например, у нас имеется ящик вида company-admin@google.com, на который хочется задать TOTP-аутентификацию через Google Authenticator (см. Authy: настройка Multi-Factor Authentication для Github и AWS). Но при этом этим ящиком пользуется несколько человек. Следовательно, что бы у всех одновременно генерировался работащий… Читать далее »