How to Set Binary Secret Values in AWS Secrets Manager Using CLI with File-Based Approach


9 views

When working with AWS Secrets Manager, you'll often need to store binary data like Java Keystores (.jks), certificates, or encrypted blobs. The CLI requires special handling for binary content since direct string passing can cause encoding issues.

Instead of trying to pass binary data directly as a variable, AWS recommends using file references. Here's the proper way:

aws secretsmanager put-secret-value \
  --secret-id your-secret-name \
  --secret-binary fileb://path/to/your/file.jks

Key points about the fileb:// prefix:

  • The b indicates binary mode (vs file:// for text)
  • This prevents any character encoding transformations
  • Works with any binary format (JKS, PKCS12, DER, etc.)

Here are some common use cases with concrete examples:

Example 1: Storing a Java Keystore

aws secretsmanager put-secret-value \
  --secret-id production-keystore \
  --secret-binary fileb:///opt/secrets/keystore.jks

Example 2: Updating a Certificate Bundle

aws secretsmanager put-secret-value \
  --secret-id ssl-certs \
  --secret-binary fileb://certs/bundle.pem

If you encounter encoding errors, verify:

  • You're using fileb:// not file://
  • The file exists and is readable
  • Your AWS CLI has sufficient permissions

For debugging, you can first test with a small binary file:

dd if=/dev/urandom of=test.bin bs=1 count=100
aws secretsmanager put-secret-value \
  --secret-id test-binary \
  --secret-binary fileb://test.bin
  • Always use fileb:// for binary content
  • Document the expected binary format in the secret description
  • Consider compression for large binaries
  • Validate retrieval after storage

When working with binary files like Java keystores (.jks), certificates, or encrypted binaries in AWS Secrets Manager, the CLI presents a common encoding hurdle. The error message you're seeing ('utf8' codec can't decode byte 0xfe in position 0') occurs because the AWS CLI expects properly encoded binary data.

The solution involves base64 encoding your binary file before passing it to the CLI:

# For Linux/macOS:
V=$(base64 -i mykeystore.jks)
aws secretsmanager put-secret-value --secret-id your-secret-id --secret-binary "$V"

# For Windows PowerShell:
$V = [Convert]::ToBase64String((Get-Content "mykeystore.jks" -Encoding Byte))
aws secretsmanager put-secret-value --secret-id your-secret-id --secret-binary "$V"

Here's a complete example for storing and retrieving a binary secret:

# Store the binary secret
base64 mykeystore.jks > encoded.jks
aws secretsmanager put-secret-value \
  --secret-id prod/keystore \
  --secret-binary file://encoded.jks

# Retrieve the secret later
aws secretsmanager get-secret-value --secret-id prod/keystore \
  --query SecretBinary --output text | base64 --decode > restored.jks

You can also reference the binary file directly without intermediate variables:

aws secretsmanager put-secret-value \
  --secret-id prod/keystore \
  --secret-binary fileb://mykeystore.jks

• Binary secrets have a size limit of 65536 bytes
• Always verify your base64 implementation (some systems use different flags)
• For security, consider cleaning up temporary files containing encoded data
• The 'fileb://' prefix specifically indicates binary file content

If you encounter errors:
1. Verify file permissions
2. Check AWS CLI version (minimum 1.16.0 for reliable binary support)
3. Ensure no special characters are mangling your base64 string
4. Test with a small binary file first