Я использую поток облачных данных Spring, развернутый в основной облачной фабрике, для запуска пакетных весенних заданий в качестве весенних облачных задач, и для этих заданий требуются учетные данные aws для доступа к корзине s3.
Я попытался передать учетные данные aws в качестве свойств задачи, но учетные данные отображаются в файлах журнала задачи как аргументы или свойства. (https://docs.spring.io/spring-cloud-dataflow/docs/current/reference/htmlsingle/#spring-cloud-dataflow-global-properties)
На данный момент я вручную устанавливаю учетные данные как переменные env в pcf после каждого развертывания, но я пытаюсь автоматизировать это. Задачи не развертываются до тех пор, пока задачи не будут фактически запущены, поэтому при развертывании я должен запустить задачу, затем дождаться ее сбоя из-за отсутствия учетных данных, а затем установить учетные данные переменной env с помощью cf cli. Как я могу предоставить эти учетные данные, чтобы они не отображались в журналах приложения pcf?
Я также исследовал использование хранилища и конфигурации облака Spring, но опять же, мне нужно будет передать учетные данные задаче для доступа к конфигурации облака Spring.
Спасибо!





Вот задача / пакетное задание пример.
Это приложение использует spring-cloud-starter-aws. И этот стартер уже предоставляет автоконфигурацию загрузки и возможность переопределить кредиты AWS как свойства загрузки.
Вы бы переопределили свойства при запуске из SCDF, например:
task launch --name S3LoaderJob --arguments "--cloud.aws.credentials.accessKey= --cloud.aws.credentials.secretKey= --cloud.aws.region.static= --cloud.aws.region.auto=false"
Вы можете решить управлять уровнем журнала Задачи, чтобы он не регистрировал их в виде обычного текста.
Безопасные учетные данные для задач должны быть настроены либо с помощью переменных среды в определении задачи, либо с помощью чего-то вроде Spring Cloud Config Server, чтобы предоставить их (и хранить их в зашифрованном виде в состоянии покоя). Spring Cloud Task хранит все аргументы командной строки в базе данных в виде открытого текста, поэтому их не следует передавать таким образом.
Что вы имеете в виду под «поражением цели»? И да, именно так будет выглядеть ваш DSL (хотя я не верю, что кавычки вокруг foo требуются).
Под «поражением цели» я подразумеваю, что если я передаю учетные данные сервера конфигурации облака Spring в качестве аргументов, я все равно передаю учетные данные, которые будут отображаться в журналах, просто другие учетные данные.
Нет, они не будут отображаться в журналах. В базе данных и в журналах должны отображаться только аргументы командной строки.
После рассмотрения подходов, включенных в предоставленные ответы, я продолжил тестирование и исследование и пришел к выводу, что лучший подход - использовать Cloud Foundry «User Provided Service» для предоставления учетных данных AWS для задачи.
https://docs.cloudfoundry.org/devguide/services/user-provided.html
Spring Boot автоматически обрабатывает переменную среды VCAP_SERVICES, включенную в контейнер каждого приложения.
http://engineering.pivotal.io/post/spring-boot-injecting-credentials/
Затем я использовал заполнители свойств в application-cloud.properties, чтобы сопоставить обработанные свойства со свойствами spring-cloud-aws:
cloud.aws.credentials.accessKey=${vcap.services.aws-s3.credentials.aws_access_key_id}
cloud.aws.credentials.secretKey=${vcap.services.aws-s3.credentials.aws_secret_access_key}
Я исследовал использование облачного сервера конфигурации Spring, но тогда мне нужно было бы передать ему учетные данные, чтобы победить цель. Не могли бы вы указать, где включить переменные среды в мои определения задач. Было бы что-то вроде
task create mytask --definition "ingest-from-s3 --cloud.aws.credentials.accessKey = "foo"