Support fileb:// for nested objects

[NukaCody]

Describe the feature

Looks like fileb:// works fine for simple arguments "--file fileb://some-local-file.txt" but it does not work for items that have an embedded file options. For example:

aws rolesanywhere create-trust-anchor --name MyCompanyTrustAnchorImported \
  --source sourceData={x509CertificateData=fileb://root-ca.crt},sourceType="CERTIFICATE_BUNDLE"  \
  --enabled

Does not work as intended. After running with --debug, I see the request gets wrapped as a string "fileb://root-ca.crt" instead of it filling in with the file contents

Use Case

PEM encoded certificates can get quite long and it's not practical to copy it manually at the command line as a "string"

Proposed Solution

No response

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

CLI version used

aws-cli/2.12.2 Python/3.11.4 Linux/4.14.255-314-253.539.amzn2.x86_64 exec-env/CloudShell exe/x86_64.amzn.2 prompt/off

Environment details (OS name and version, etc.)

Amazon Linux 2 / Cloudshell

[tim-finnigan]

Thanks for the feature request — I'll mark this for further review by the team. In the meantime others can 👍 the issue and comment here to share any additional use cases.

[aemous]

Feature is released in v2 2.20.0. The usage of the command in the request would be

aws rolesanywhere create-trust-anchor --name MyCompanyTrustAnchorImported \
  --source sourceData={x509CertificateData@=file://root-ca.crt},sourceType="CERTIFICATE_BUNDLE"  \
  --enabled

The only difference from the request is the need for the @= operator. Similarly, fileb:// can be used the same way. However, for this particular API create-trust-anchor, source.sourceData. x509CertificateData must be of type string, not bytes.

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.