Долгоживущий основанный на ключе / токене способ загрузки объектов хранилища Google с помощью curl? - PullRequest
Новая
       15

Долгоживущий основанный на ключе / токене способ загрузки объектов хранилища Google с помощью curl?

0 голосов
/ 19 июня 2019

Хорошо, мои товарищи по разработке и программистам.Я провел последнюю неделю, пытаясь выяснить это с помощью облачных хранилищ Google (GCP).Вот моя цель.

  1. Решение должно быть легким, поскольку оно будет использоваться для загрузки изображений внутри образа докера, отсюда и требование скручивания.
  2. Ведро и объект GCPдолжен быть безопасным и не общедоступным.
  3. Мне нужен "долгоживущий" билет / ключ / client_ID.

Я пробовал настройку OAuth2.0, о которой упоминается в документации Google, но каждый разЯ хочу настроить ключ OAuth2.0, если у меня нет возможности иметь «автономный» доступ.И чтобы завершить его, необходимо указать исходные URL-адреса, которые будут обращаться к запросу на авторизацию.

Кроме того, облачное хранилище Google не поддерживает ключ =, как некоторые другие их службы.Поэтому здесь у меня есть API-ключ для моего проекта, а также файл OAuth JSON для моего пользователя службы, и они бесполезны.

Я могу получить команду curl для работы с временным ключом-носителем OAuth, но мне нужнодолгосрочное решение для этого. 

RUN curl -X GET \
    -H "Authorization: Bearer ya29.GlsoB-ck37IIrXkvYVZLIr3u_oGB8e60UyUgiP74l4UZ4UkT2aki2TI1ZtROKs6GKB6ZMeYSZWRTjoHQSMA1R0Q9wW9ZSP003MsAnFSVx5FkRd9-XhCu4MIWYTHX" \
    -o "/home/shmac/test.tar.gz" \
    "https://www.googleapis.com/storage/v1/b/mybucket/o/my.tar.gz?alt=media"

Долгосрочный ключ / ID / секрет, который позволит мне загружать объект корзины GCP из любого места.

1 Ответ

1 голос
/ 20 июня 2019

Решение должно быть легким, так как оно будет использоваться для загрузки изображения внутри образа докера, отсюда и требование скручивания.

Это расплывчатое требование. Что такое легкий? Нет внешних библиотек, все написано на ассемблере, должно умещаться в 1 КБ и т. Д.

Ведро и объект GCP должны быть безопасными, а не общедоступными.

Это нормальное требование. За некоторыми исключениями (статическое хранилище файлов для веб-сайтов и т. Д.) Вы хотите, чтобы ваши корзины были частными.

Мне нужен "долгоживущий" билет / ключ / client_ID.

Мой совет - перестать думать о «долгосрочных ключах». Тенденция в безопасности заключается в реализации краткосрочных ключей. В Google Cloud Storage семидневный период считается долгосрочным. 3600 секунд (один час) - это норма почти везде в Google Cloud.

Для Google Cloud Storage у вас есть несколько вариантов. Вы не указали среду, поэтому я включу как учетные данные пользователя, учетную запись службы, так и доступ на основе предварительно назначенного URL-адреса.

Учетные данные пользователя

Вы можете пройти аутентификацию с использованием учетных данных пользователя (например, username@gmail.com) и сохранить маркер обновления. Затем, когда требуется токен доступа, его можно сгенерировать из токена обновления. В своей статье на веб-сайте об изучении языка Go я написал в День № 8 программу, которая реализует Google OAuth, сохраняет необходимые учетные данные и создает токены доступа и идентификационные токены, как требуется, без необходимости дальнейшего входа в систему. Комментарии в исходном коде должны помочь вам понять, как это делается. https://www.jhanley.com/google-cloud-and-go-my-journey-to-learn-a-new-language-in-30-days/#day_08

Это выбор, если вам нужно использовать учетные данные пользователя. Этот метод более сложный, требует защиты файла секретов, но даст вам обновляемые долгосрочные токены.

Учетные данные учетной записи службы

Файлы ключей JSON служебной учетной записи - это стандартный метод аутентификации и авторизации между сервисами. Используя эти ключи, генерируются токены доступа, действительные в течение одного часа. Когда они истекают новые создаются. Максимальное время составляет 3600 секунд.

Это выбор, если вы программно обращаетесь к облачному хранилищу с помощью программ, находящихся под вашим контролем (файл JSON служебной учетной записи должен быть защищен).

Presigned-адрес

Это стандартный метод предоставления доступа к частным объектам Google Cloud Storage. Этот метод требует URL и генерирует подпись с истечением срока действия, так что объекты могут быть доступны в течение определенного периода времени. Одно из ваших требований (которое нереально) заключается в том, что вы не хотите использовать исходные URL-адреса. Максимальное время составляет семь дней.

Это выбор, если вам необходимо предоставить доступ третьим сторонам для доступа к вашим объектам облачного хранилища.

Доступ на основе IAM

Этот метод не использует жетоны доступа, вместо этого он использует жетоны идентификации. Разрешения назначаются корзинам и объектам облачного хранилища, а не учетной записи участника IAM. Этот метод требует четкого понимания того, как работают удостоверения в облачном хранилище Google, и является будущим направлением безопасности Google. Это означает, что доступ ко многим службам будет контролироваться на основе услуг / объектов, а не с помощью ролей, которые предоставляют широкий доступ ко всей службе в проект. Я говорю об этом в моей статье о Identity Based Access Control

Резюме

Вы не четко определили, что будет иметь доступ к облачному хранилищу, как хранятся секреты, нужно ли защищать секреты от пользователей (общедоступный доступ по URL) и т. Д. Выбор зависит от ряда факторов.

Если вы читаете последние статьи на моем веб-сайте, я обсуждаю ряд передовых методов управления доступом на основе идентификационных данных.Эти функции начинают появляться в ряде сервисов Google в командах бета-уровня.Это включает в себя Cloud Scheduler, Cloud Pub / Sub, Cloud Functions, Cloud Run, Cloud KMS и многое другое.Облачное хранилище поддерживает доступ на основе удостоверений, который вообще не требует никаких разрешений - удостоверение используется для управления доступом.

...