Сохраненные переменные конфигурации времени выполнения Google Deployment Manager повреждены

У меня проблемы с зашифрованными значениями в кодировке base64, которые я использую в Google Deployment Manager через объявления ресурсов runtimeconfig.v1beta1.config.

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

Сначала я зашифровал и закодировал в base64 какой-то секретный текст:

$ echo "secret"|gcloud kms encrypt --key my-crypto-key \
  --keyring my-keyring --location australia-southeast1 \
  --plaintext-file - --ciphertext-file - | base64 -w0

CiQAsOSNmVXBs2ayUjRePnE5+Oi5dUPuVvjn6UKKUXgxMTA56koSMABDkVUGnXlocFgdUEsQ5qLCF3PVIz5zit+ZCSXjSvNzEAO5XRv6WBRkxBJMjVcheg==

Что я затем сохраняю в файле YAML диспетчера развертывания:

resources:
- name: my-config
  type: runtimeconfig.v1beta1.config
  properties:
    config: my-config
    description: "A demo configuration"

- name: dummy-secret
  type: runtimeconfig.v1beta1.variable
  properties:
    parent: $(ref.my-config.name)
    variable: 'dummy/secret'
    value: "CiQAsOSNmVXBs2ayUjRePnE5+Oi5dUPuVvjn6UKKUXgxMTA56koSMABDkVUGnXlocFgdUEsQ5qLCF3PVIz5zit+ZCSXjSvNzEAO5XRv6WBRkxBJMjVcheg=="

Затем я создаю развертывание (которое завершается без ошибок и предупреждений):

$ gcloud deployment-manager deployments create my-config \
  --config my-config.yaml

Но когда я пытаюсь извлечь значение переменной, оно полностью отличается от того, что я сохранил:

$ gcloud beta runtime-config configs variables \
  get-value 'dummy/secret' --config-name my-config|base64 -w0
CiQAPz8/P1U/P2Y/UjRePnE5Pz8/dUM/Vj8/P0I/UXgxMTA5P0oSMABDP1UGP3locFgdUEsQPz8/F3M/Iz5zPz8/CSU/Sj9zEAM/XRs/WBRkPxJMP1cheg==

Это можно повторить / воспроизвести, и я понятия не имею, что я делаю не так. У меня нет этой проблемы с использованием gcloud beta runtime-config variables set, за которым следует get-value.


google-cloud-platform google-cloud-kms google-deployment-manager
person Poo Bah    schedule 12.07.2018    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Глядя на декодированный двоичный файл base64 вашего контента, мы замечаем, что все байты со значениями> = 0x80 были изменены на 0x3F, ASCII '?'. Мы подозреваем, что вы передаете двоичные данные через оболочку или другой канал, который не является двоично-чистым.

Поврежденное значение:

dierks@dierks:~$ base64 -d | hexdump -C
CiQAPz8/P1U/P2Y/UjRePnE5Pz8/dUM/Vj8/P0I/UXgxMTA5P0oSMABDP1UGP3locFgdUEsQPz8/F3M/Iz5zPz8/CSU/Sj9zEAM/XRs/WBRkPxJMP1cheg==
00000000  0a 24 00 3f 3f 3f 3f 55  3f 3f 66 3f 52 34 5e 3e  |.$.????U??f?R4^>|
00000010  71 39 3f 3f 3f 75 43 3f  56 3f 3f 3f 42 3f 51 78  |q9???uC?V???B?Qx|
00000020  31 31 30 39 3f 4a 12 30  00 43 3f 55 06 3f 79 68  |1109?J.0.C?U.?yh|
00000030  70 58 1d 50 4b 10 3f 3f  3f 17 73 3f 23 3e 73 3f  |pX.PK.???.s?#>s?|
00000040  3f 3f 09 25 3f 4a 3f 73  10 03 3f 5d 1b 3f 58 14  |??.%?J?s..?].?X.|
00000050  64 3f 12 4c 3f 57 21 7a                           |d?.L?W!z|
00000058

Исходное значение:

dierks@dierks:~$ base64 -d | hexdump -C
CiQAsOSNmVXBs2ayUjRePnE5+Oi5dUPuVvjn6UKKUXgxMTA56koSMABDkVUGnXlocFgdUEsQ5qLCF3PVIz5zit+ZCSXjSvNzEAO5XRv6WBRkxBJMjVcheg==
00000000  0a 24 00 b0 e4 8d 99 55  c1 b3 66 b2 52 34 5e 3e  |.$.....U..f.R4^>|
00000010  71 39 f8 e8 b9 75 43 ee  56 f8 e7 e9 42 8a 51 78  |q9...uC.V...B.Qx|
00000020  31 31 30 39 ea 4a 12 30  00 43 91 55 06 9d 79 68  |1109.J.0.C.U..yh|
00000030  70 58 1d 50 4b 10 e6 a2  c2 17 73 d5 23 3e 73 8a  |pX.PK.....s.#>s.|
00000040  df 99 09 25 e3 4a f3 73  10 03 b9 5d 1b fa 58 14  |...%.J.s...]..X.|
00000050  64 c4 12 4c 8d 57 21 7a                           |d..L.W!z|
person Tim Dierks    schedule 12.07.2018
comment
Привет, Тим! Команда gcloud encrypt выводит двоичный файл в моем первом кодовом блоке, приведенном выше, но конвейер не повреждает его там, так как я могу взять полученное значение в кодировке base64, сохранить напрямую с помощью gcloud: gcloud beta runtime-config configs variables set 'dummy/secret' "CiQA[SNIP]" --config-name my-config И его все еще можно расшифровать: gcloud beta runtime-config configs variables get-value 'dummy/secret' --config-name my-config|base64 -d | gcloud kms decrypt --key my-crypto-key --keyring my-keyring .. --plaintext-file - --ciphertext-file - secret - person Poo Bah; 13.07.2018
comment
OK. Я ничего не знаю о диспетчере развертывания (я работаю с KMS), но вижу, что ценность, которую вы получаете от KMS, выглядит нормально. Я не знаю, искажается ли значение из-за того, что старшие битовые октеты заменяются на '?' на пути к развертыванию или на выходе. GI Даже то, что это кодировка base64 в файле YAML, кодирование этого файла не проблема. Если вы можете установить значение с помощью gcloud и получить его обратно, то проблемы с gcloud и извлечением значений вряд ли возникнут. Так может быть парсер YAML? Я пингую кого-нибудь из команды. - person Tim Dierks; 13.07.2018
comment
Обходной путь - изменить YAML таким образом, чтобы свойство фиктивного секрета 'value' было изменено на 'text', в результате чего зашифрованный секрет в кодировке base64 сохранялся в виде строки в runtime-config. - person Poo Bah; 15.07.2018
comment
Подняли заявку в Google: Issuesetracker.google.com/issues/111407084 - person Poo Bah; 15.07.2018
comment
Это ошибка в gcloud. По указанному выше билету. - person Poo Bah; 18.07.2018