Comments 14
трайба IT4IT ОТП Банка
Вы там правда себя так идентифицируете? Принадлежностью к племенам? Это часть корпкультуры или просто Вам слово импонирует?
Однако на нём самоподписанные сертификаты
Так а не проще было просто повесить на Nexus валидные сертификаты?
> Те читатели, кто занимается инфобезом в финтехе, сейчас, наверное, или смеются, или в ужасе думают о последствиях такого решения.
Создавал инфру для финтеха в облаке AWS. Не вижу в этом ничего ужасного или смешно. Да и over 9000 финтех компаний в мире тоже не видят в этом ничего такого.
Кейс отличный, но вариант сопряжения с облаком, когда свою железку ставишь в дата-центр yandex'а, очень сложный и мало кому подойдёт + в случае сетевых проблем техподдержка облака будет долго тупить, т.к. не будет знать о вашей особой конфигурации подключения.
Наше оборудование стоит в одном из московских ЦОДов рядом с сетевым оборудованием Яндекса и физически подключено к нему. То есть, это ЦОД яндекса, это одна из их "точек присутствия" где к ним можно подключится. Про точки присутствия можно посмотреть, например, тут: https://cloud.yandex.ru/ru/docs/interconnect/concepts/pops
Два банка на одной платформе.
историю с модификацией конфига containerd в похожей ситуации на основе https://github.com/yandex-cloud/yc-architect-solution-library/tree/main/yc-k8s-certificate-updater я решил на базе image: cr.yandex/yc/mk8s-openssl:stable
У нас тоже внутренний Certificate Authority и весь выход наружу через корпоративнй прокси. Соответственно нужно всунуть серты от корпоративного CA, настроить прокси-сервер и NTP, чтобы время на нодах не разъезжалось из-за отсутствия коннективити с корневыми NTP в Интернете. Правки на нодах минимальны. Работает стабильно. Скрипт прокатывается один раз при смене содержимого секрета internal-certificates
---
apiVersion: "apps/v1"
kind: DaemonSet
metadata:
name: certificate-updater
namespace: certificate-updater
labels:
k8s-app: certificate-updater
spec:
selector:
matchLabels:
k8s-app: certificate-updater
template:
metadata:
labels:
k8s-app: certificate-updater
spec:
hostPID: true
hostIPC: true
hostNetwork: true
containers:
- name: certificate-updater
image: cr.yandex/yc/mk8s-openssl:stable
command:
- sh
- -c
- |
while true; do
diff -x '.*' -r /mnt/user-cert-path/ /usr/local/share/ca-certificates
if [ $? -ne 0 ]; then
# setup proxy for containerd
mkdir -p /etc/systemd/system/containerd.service.d
cat <<-EOF > /etc/systemd/system/containerd.service.d/proxy.conf
[Service]
Environment="NO_PROXY=172.17.0.1,localhost,127.0.0.1,harbor.corp"
Environment="HTTP_PROXY=http://<proxy-ip>:3128"
Environment="HTTPS_PROXY=http://<proxy-ip>:3128"
EOF
ls -laF /etc/systemd/system/containerd.service.d/proxy.conf
cat /etc/systemd/system/containerd.service.d/proxy.conf
# prepare time settings
mkdir -p /etc/systemd/timesyncd.conf.d
cat <<-EOF > /etc/systemd/timesyncd.conf.d/corporate.conf
[Time]
NTP=10.0.0.11 10.0.0.12 10.0.0.15
FallbackNTP=ntp0.NL.net clock.isc.org ntp2.vniiftri.ru ntps1-1.cs.tu-berlin.de ntp.ix.ru
EOF
chmod 644 /etc/systemd/timesyncd.conf.d/corporate.conf
chown root:root /etc/systemd/timesyncd.conf.d/corporate.conf
# setup certificates
echo "Removing all old certificates"
rm -r /usr/local/share/ca-certificates/*
echo "Copying certificates from configmap"
cp /mnt/user-cert-path/* /usr/local/share/ca-certificates
nsenter -t 1 -m -u -n -i sh -xc "
update-ca-certificates && \
systemctl daemon-reload && \
timedatectl set-timezone Europe/Moscow && \
systemctl enable --now systemd-timesyncd && \
systemctl restart systemd-timesyncd && \
systemctl restart containerd
"
else
echo "Doing Nothing as no certs has not been changned"
fi
sleep 30
done
imagePullPolicy: IfNotPresent
securityContext:
privileged: true
resources:
limits:
cpu: 200m
memory: 200Mi
requests:
cpu: 100m
memory: 100Mi
volumeMounts:
- mountPath: /etc/
name: etc
- mountPath: /usr/local/share/ca-certificates
name: docker-cert
- name: secret
mountPath: /mnt/user-cert-path
- name: ca-cert
mountPath: /usr/share/ca-certificates
volumes:
- name: secret
secret:
secretName: internal-certificates
- name: ca-cert
hostPath:
path: /usr/share/ca-certificates
type: Directory
- name: docker-cert
hostPath:
path: /usr/local/share/ca-certificates
type: DirectoryOrCreate
- name: etc
hostPath:
path: /etc/
type: Directory
Спасибо за предложенный вариант! Вариант проверки через diff ca-certificates явно лучше. Единственное, мы NTP сервера настраиваем через настройку DHCP подсетей.https://cloud.yandex.ru/ru/docs/vpc/concepts/dhcp-optionshttps://cloud.yandex.ru/ru/docs/vpc/operations/subnet-create
ни чего, что то, что находится в облаке, вам не принадлежит?
Как вообще отдел безопасности это пропустил? (может я что пропустил и в облаке оказывается не хранится важная информация?)
На это намекали в первом абзаце статьи "мы выполнили требования Управления информационной безопасности (УИБ) никого не впускать и не выпускать — не забыв при этом сделать облако мощным инструментом для наших разработчиков." Публичное облако в основном используют для дев и тест стендов, так как это дает возможность быстро (ускоряя бюрократические моменты по выделению временных ресурсов) и гибко разворачивать инфраструктуру, что существенно сокращает время на разработку. Категоризация данных осуществляется еще на этапе проектирования сервисов и исключает хранение и обработку чувствительных данных в публичных облаках, так как это обеспечивает более удобный и полный контроль. (не потому что мы ставим под сомнение надежность Яндекс облака https://cloud.yandex.ru/ru/docs/security/conform, а потому что нам так удобнее). Для промышленного контура в компании активно используется приватное облако, о чем уже писали в ранних статьях.
Я вот читаю такие комменты и не могу понять
Первое: а что, правда можно выкладывать детали внутренней реализации и проектов? Я конечно не скажу за всех, но по идее меня бы за такое по голове не погладили. Разве что есть какой-то фильтр, который читает написанное 100500 раз и нещадно режет. По собственной инициативе писать такое на публичном ресурсе ...
Второе: я понимаю, что часто есть ограничения отрасли и не только, которые вынуждают изобретать велосипед. Но в целом - как по мне, вся причина в том, что банально инфобез живет в прошлом и тупо лениться прорабатывать концепцию безопасного развертывания в облаке. Поэтому выходит что-то непонятное, но наверное круто
Облако для тех, кому нельзя в облака: как мы в ОТП Банке развернули закрытое облако на платформе Яндекса