#google-cloud-platform #google-cloud-functions
#google-облачная платформа #google-cloud-функции
Вопрос:
Некоторым функциям, которые я пишу, потребуется где-то хранить и совместно использовать набор криптографических ключей (<1 КБ), чтобы:
- он используется для всех функций и в экземплярах одной и той же функции
- он поддерживается после развертывания функции
Ключи изменяются (и записываются) примерно каждые 4 часа в зависимости от того, истек срок действия ключа или необходимо создать новый ключ.
Прямо сейчас я храню ключи в виде зашифрованного двоичного файла в облачной корзине с ограниченным доступом к этой функции. Он работает, за исключением того, что он довольно медленный (~ 500 мс для чтения / записи, которые требуются при обновлении ключей).
Я рассмотрел некоторые другие решения:
- Redis: быстро, но излишне, учитывая цену (40 долларов США в месяц), которая будет стоить для хранения одного значения
- Облачный SQL: функции уже подключены к облачному экземпляру, поэтому это не повлечет дополнительных затрат
- Отбрасываем все и используем KMS. К сожалению, это не соответствует моим требованиям.
Библиотека, которую я использую в своих функциях, доступна здесь .
Есть ли лучший способ сохранить один небольшой большой двоичный объект данных для облачных функций (и, возможно, других инструментов, таких как GKE)?
Редактировать
Решение, которое я в конечном итоге использовал, использовало единственную таблицу в базе данных, к которой приложение уже было подключено. Это также примерно в 5 раз быстрее, чем при использовании корзины (<100 мс).
Мораль этой истории заключается в том, чтобы использовать все, что уже предусмотрено для хранения ключей. Если хранение ключа является проблемой, то использование комбинированных функций KMS cloud для вращения, описанных ниже, кажется хорошим вариантом.
Весь код более подробная информация доступны здесь.
Комментарии:
1. Если производительность облачного хранилища является проблемой, практически любое другое решение будет работать медленнее. Такие сервисы, как KMS, Secrets Manager, Firestore и т. Д., Хранят свои секреты в постоянном хранилище и в большинстве случаев используют гораздо более сложные схемы хранения.
Ответ №1:
Лучшим подходом было бы управлять вашими ключами с помощью Cloud KMS. Однако, как вы упоминали ранее, Cloud KMS не удаляет автоматически старые версии ключей, и вам нужно будет вручную удалять старые версии, что, как я подозреваю, является тем, что вы не хотите делать.
Другая возможность — просто хранить ключи в Firestore. Поскольку для этого вам не нужно предоставлять какую-либо конкретную инфраструктуру, например, с Redis Memorystore и Postgres Cloud SQL, в долгосрочной перспективе будет проще управлять и масштабировать.
Общая идея заключается в том, чтобы иметь облачную функцию, запускаемую Cloud Scheduler каждые 4 часа, и эта функция будет вращать ключи в вашем облачном хранилище Firestore.
Как это звучит для вас?
Комментарии:
1. Это отличная идея. Я не рассматривал ни облачный Firestore, ни разделение выполнения от поворота ключа. Основная сложность последнего заключается в том, чтобы гарантировать, что выполнение всегда точно знает, когда произошла ротация, чтобы оно могло соответствующим образом кэшировать ключи. Я думаю, что, вероятно, лучшим гибридом было бы иметь облачную KMS, выполняющую шифрование, и набор облачных функций, выполняющих ротацию. Таким образом, нет необходимости проверять актуальность ключей или даже кэшировать их. Я попробую это сейчас.