II
использовать волт?
Size: a a a
2020 July 01
L
использовать волт?
вариант 2 - вид сбоку с рюшечками
II
вариант 2 - вид сбоку с рюшечками
С подворотами =)
II
с п1 это прямой путь к статье в стиле "слита база паролей бла бла"
HC
Вопрос не по кубернетесу, но вдруг кто-нибудь сталкивался: есть какие-нибудь бест-практисы, как лучше хранить пароли в БД?
Вариант "не хранить пароль, хранить соленый хэш" подходит, если нужно только проверять время от времени прилетающий извне пароль, но у меня другой юзкейс - хранить нужно креденшелы для автоматизированного доступа в третью систему. Т.е. мне таки нужно иметь возможность прочитать исходный пароль.
Вариантов вижу 2:
1) Хранить плейнтекстом и молиться, что конкретно эту базу не взломают.
2) Шифровать данные ключом, который приложению передается через окружение, и расшифровывать им же при чтении из БД. Звучит не намного более секьюрно.
Есть ли какие-нибудь другие идеи?
Вариант "не хранить пароль, хранить соленый хэш" подходит, если нужно только проверять время от времени прилетающий извне пароль, но у меня другой юзкейс - хранить нужно креденшелы для автоматизированного доступа в третью систему. Т.е. мне таки нужно иметь возможность прочитать исходный пароль.
Вариантов вижу 2:
1) Хранить плейнтекстом и молиться, что конкретно эту базу не взломают.
2) Шифровать данные ключом, который приложению передается через окружение, и расшифровывать им же при чтении из БД. Звучит не намного более секьюрно.
Есть ли какие-нибудь другие идеи?
скорее всего 2-й вариант, примерно по такой схеме сделано у Jenkins с кредами. Они вроде и зашифрованы, но исходные посмотреть можно
L
Вопрос не по кубернетесу, но вдруг кто-нибудь сталкивался: есть какие-нибудь бест-практисы, как лучше хранить пароли в БД?
Вариант "не хранить пароль, хранить соленый хэш" подходит, если нужно только проверять время от времени прилетающий извне пароль, но у меня другой юзкейс - хранить нужно креденшелы для автоматизированного доступа в третью систему. Т.е. мне таки нужно иметь возможность прочитать исходный пароль.
Вариантов вижу 2:
1) Хранить плейнтекстом и молиться, что конкретно эту базу не взломают.
2) Шифровать данные ключом, который приложению передается через окружение, и расшифровывать им же при чтении из БД. Звучит не намного более секьюрно.
Есть ли какие-нибудь другие идеи?
Вариант "не хранить пароль, хранить соленый хэш" подходит, если нужно только проверять время от времени прилетающий извне пароль, но у меня другой юзкейс - хранить нужно креденшелы для автоматизированного доступа в третью систему. Т.е. мне таки нужно иметь возможность прочитать исходный пароль.
Вариантов вижу 2:
1) Хранить плейнтекстом и молиться, что конкретно эту базу не взломают.
2) Шифровать данные ключом, который приложению передается через окружение, и расшифровывать им же при чтении из БД. Звучит не намного более секьюрно.
Есть ли какие-нибудь другие идеи?
ну пароли от БД ты же передаешь в приложение. с ключом шифрования то же самое.
R
Ок, значит, остается шифровать ключом. Спасибо за ответы
DB
Вопрос не по кубернетесу, но вдруг кто-нибудь сталкивался: есть какие-нибудь бест-практисы, как лучше хранить пароли в БД?
Вариант "не хранить пароль, хранить соленый хэш" подходит, если нужно только проверять время от времени прилетающий извне пароль, но у меня другой юзкейс - хранить нужно креденшелы для автоматизированного доступа в третью систему. Т.е. мне таки нужно иметь возможность прочитать исходный пароль.
Вариантов вижу 2:
1) Хранить плейнтекстом и молиться, что конкретно эту базу не взломают.
2) Шифровать данные ключом, который приложению передается через окружение, и расшифровывать им же при чтении из БД. Звучит не намного более секьюрно.
Есть ли какие-нибудь другие идеи?
Вариант "не хранить пароль, хранить соленый хэш" подходит, если нужно только проверять время от времени прилетающий извне пароль, но у меня другой юзкейс - хранить нужно креденшелы для автоматизированного доступа в третью систему. Т.е. мне таки нужно иметь возможность прочитать исходный пароль.
Вариантов вижу 2:
1) Хранить плейнтекстом и молиться, что конкретно эту базу не взломают.
2) Шифровать данные ключом, который приложению передается через окружение, и расшифровывать им же при чтении из БД. Звучит не намного более секьюрно.
Есть ли какие-нибудь другие идеи?
шифровать, да
GG
Вопрос не по кубернетесу, но вдруг кто-нибудь сталкивался: есть какие-нибудь бест-практисы, как лучше хранить пароли в БД?
Вариант "не хранить пароль, хранить соленый хэш" подходит, если нужно только проверять время от времени прилетающий извне пароль, но у меня другой юзкейс - хранить нужно креденшелы для автоматизированного доступа в третью систему. Т.е. мне таки нужно иметь возможность прочитать исходный пароль.
Вариантов вижу 2:
1) Хранить плейнтекстом и молиться, что конкретно эту базу не взломают.
2) Шифровать данные ключом, который приложению передается через окружение, и расшифровывать им же при чтении из БД. Звучит не намного более секьюрно.
Есть ли какие-нибудь другие идеи?
Вариант "не хранить пароль, хранить соленый хэш" подходит, если нужно только проверять время от времени прилетающий извне пароль, но у меня другой юзкейс - хранить нужно креденшелы для автоматизированного доступа в третью систему. Т.е. мне таки нужно иметь возможность прочитать исходный пароль.
Вариантов вижу 2:
1) Хранить плейнтекстом и молиться, что конкретно эту базу не взломают.
2) Шифровать данные ключом, который приложению передается через окружение, и расшифровывать им же при чтении из БД. Звучит не намного более секьюрно.
Есть ли какие-нибудь другие идеи?
vault?
GG
ценность вольта не только в шифровании, но и в аудит логе того, кто и когда ходил за секретами + возможность настроить процессы (типа ротейшена секретов)
R
vault?
У меня приложение не только использует пароль, но и генерирует его само же. Удобнее складывать в уже существующую БД, в которую оно и так ходит
GG
У меня приложение не только использует пароль, но и генерирует его само же. Удобнее складывать в уже существующую БД, в которую оно и так ходит
ник поменяй 0
4
с подключением
DH
коллеги, подскажите что делать если пакет при отправке с ноды на elb, у которой таргетом служит та же нода - по возвращению на ноду дропается?
DH
я так понимаю это calico iptables
DH
получается source ip тот же самый что и у самой ноды
DH
пакет помечается как invalid и дропается вместо чтого, чтоб вернуться обратно на elb
LR
Добрый день! Нужен Kubernetes - профессионал, задача - внедрение и дальнейшая поддержка и развитие. Позиция удаленная
GG
Larisa Remneva
Добрый день! Нужен Kubernetes - профессионал, задача - внедрение и дальнейшая поддержка и развитие. Позиция удаленная