Базовая авторизация для команды Curl в секрете openshift

У меня есть веб-сервер Apache с URL-адресом, защищенным базовой аутентификацией e.x.

www.example.com/protected/

В моем Dockerfile в Openshift, когда я создаю образ, у меня есть команды curl, которые загружают файлы. Теперь эта команда curl с базовой аутентификацией будет выглядеть так при использовании базовой аутентификации

curl -u имя пользователя: пароль http://www.example.com/protected/

Проблема в том, что я не хочу отображать имя пользователя: пароль в Dockerfile. Вместо этого я хочу скрыть учетные данные в секрете Openshift / Kubernetes

Обычно файл yaml openshift для определения секрета в начале выглядит так:

kind: Secret
  apiVersion: v1
    metadata:
     name: secret-name
    data:

Вопрос: Как мне добавить создание правильного секретного файла для базовых учетных данных аутентификации и как затем ссылаться на него из Dockerfile?


kubernetes docker openshift openshift-enterprise openshift-origin
person bortek    schedule 23.03.2017    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Ознакомьтесь с секретами сборки а также прочтите , как они работают со стратегией Docker < / а>.

Чтобы использовать этот секрет с командой curl, я бы предложил использовать параметр -K с путем к секрету.

person Slava Semushin    schedule 23.03.2017

arrow_upward
0
arrow_downward

закончил создание этого секрета (формат yaml). Данные в файле .curl-secret должны быть в кодировке base64, который декодируется в команде curl в Dockerfile (ниже).

apiVersion: v1
data:
  .curl-secret: <YOUR_SECRET_HERE>
kind: Secret
metadata:
  creationTimestamp: null
  name: curl-secret
type: Opaque

а затем в конфигурации сборки добавляем ссылку на секрет.

  source:
    type: Git
    git:
      uri: 'https://GITHUB.URL'
      ref: master
    secrets:
      - secret:
          name: curl-secret

Затем в Dockerfile я копирую этот файл, использую его, а затем удаляю.

COPY .curl-secret /tmp
curl -u $(cat /tmp/.curl-secret) -s -o /output.file
rm /tmp/.curl-secret
person bortek    schedule 27.03.2017
comment
К сожалению, этот подход небезопасен, потому что, когда вы используете COPY, docker создает отдельный слой с вашим секретным файлом внутри. Таким образом, секретный файл все еще существует и может быть раскрыт позже. - person Slava Semushin; 28.03.2017