Используйте учетную запись службы IAM с официальным изображением Google / Cloud-SDK - PullRequest
Новая
       26

Используйте учетную запись службы IAM с официальным изображением Google / Cloud-SDK

0 голосов
/ 05 февраля 2019

Context

У меня есть скрипт bash, который использует инструмент командной строки gcloud для выполнения операций обслуживания.

Этот скрипт работает нормально.

Этот сценарий находится в образе докера на основе google/cloud-sdk, автоматически выполняемого непосредственно через точку входа в контейнер.

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

В настоящее время я ничего не настроил в отношении аутентификации, поэтому мой сценарий использует учетную запись службы Compute Engine по умолчанию .

Пока все хорошо, но янеобходимо прекратить использование этой учетной записи службы по умолчанию и переключиться на отдельную учетную запись службы с файлом ключа API.Вот где начинаются проблемы.

Проблема

Я планировал смонтировать мой ключ API в контейнере с помощью секрета Kubernetes, а затем использовать GOOGLE_APPLICATION_CREDENTIALS (задокументировано здесь ) чтобы он загружался автоматически со следующей (упрощенной) конфигурацией: 

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: some-name
spec:
  schedule: "0 1 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: some-name
              image: some-image-path
              imagePullPolicy: Always
              env:
                - name: GOOGLE_APPLICATION_CREDENTIALS
                  value: "/credentials/credentials.json"
              volumeMounts:
                - name: credentials
                  mountPath: /credentials
          volumes:
            - name: credentials
              secret:
                secretName: some-secret-name

Но, очевидно, инструмент gcloud ведет себя не так, как SDK на языках программирования, и полностью игнорирует эту переменную env.

Документация об изображении также мало чем поможет, поскольку дает вам только возможность изменить расположение конфигурации gcloud.

Более того, я уверен, что яМне понадобится способ предоставить некоторую дополнительную конфигурацию для gcloud в будущем (проект, зона и т. д.), поэтому я думаю, что мое решение должно дать мне возможность сделать это с самого начала.

Возможнорешения

Я нашел несколько способов обойти эту проблему:

  • Измените сценарий точки входа моего образа, чтобы прочитать переменные среды и выполнить envподготовка с помощью gcloud команд:

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

  • Переопределите точку входа моего изображения с помощью KuMernetes configMap, смонтированного какfile:

    Эта опция, вероятно, наиболее удобна: выполнить отдельный файл конфигурации для каждой среды, где я могу выполнить любую настройку среды, какую захочу (например, gcloud auth activate-service-account --key-file /credentials/credentials.json).Тем не менее, он выглядит хакерским и трудно читаемым по сравнению с переменными env.

  • Вручную предоставьте файлы конфигурации для gcloud (в /root/.config/gcloud):

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

Как видите, я нашел способы обойти мою проблему, но ни один из них не удовлетворяет меня полностью.Я что-то пропустил?

1 Ответ

0 голосов
/ 06 февраля 2019

Для справки, вот решение, которое я наконец-то использовал, хотя, на мой взгляд, это обходной путь: 

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: some-name
spec:
  schedule: "0 1 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: some-name
              image: some-image-path
              imagePullPolicy: Always
              command: ["/bin/bash", "/k8s-entrypoint/entrypoint.sh"]
              volumeMounts:
                - name: credentials
                  mountPath: /credentials
                - name: entrypoint
                  mountPath: /k8s-entrypoint
          volumes:
            - name: credentials
              secret:
                secretName: some-secret-name
            - name: entrypoint
              configMap:
                name: entrypoint

Со следующим ConfigMap: 

apiVersion: v1
kind: ConfigMap
metadata:
  name: entrypoint
data:
  entrypoint.sh: |
    #!/bin/bash

    gcloud auth activate-service-account --key-file /credentials/credentials.json

    # Chainload the original entrypoint
    exec sh -c /path/to/original/entrypoint.sh
...