Security

Cloodsy S3 implements multiple security layers to protect your data.

Authentication

AWS Signature v4

All API requests are authenticated using AWS Signature Version 4, the same protocol used by AWS S3. This ensures:

  • Request integrity (HMAC-SHA256 signing)
  • Credential protection (secrets never sent over the wire)
  • Replay protection (timestamp validation)
  • Chunked transfer encoding support

Per-bucket Credentials

Each bucket has its own access keys, providing full isolation:

# Create credentials for a specific bucket
./cloodsys3 credential create photos

# Create read-only credentials
./cloodsys3 credential create photos --readonly

# Revoke a credential
./cloodsys3 credential revoke AKIAIOSFODNN7EXAMPLE

Credentials for one bucket cannot access another bucket's data.

Read-only Mode

Read-only credentials allow only these operations:

  • GetObject — download objects
  • HeadObject — check object metadata
  • ListObjectsV2 — list objects in a bucket
  • HeadBucket — check if bucket exists
  • ListBuckets — list accessible buckets

All write operations (PutObject, DeleteObject, etc.) are rejected with 403 Forbidden.

Path Traversal Protection

All object keys are validated before processing:

  • .. sequences are rejected
  • Absolute paths are rejected
  • Null bytes are rejected
  • Keys are normalized to prevent directory escape

Atomic Writes

Objects are never written directly to their final path:

  1. Data is written to a temporary file in the same directory
  2. The temporary file is synced to disk (fsync)
  3. The file is atomically renamed to the final path

This prevents partial or corrupted files in case of crash or power loss.

TLS

Enable TLS for encrypted connections:

./cloodsys3 serve --tls-cert /path/to/cert.pem --tls-key /path/to/key.pem

In production, always use TLS or place Cloodsy S3 behind a TLS-terminating reverse proxy.

Recommendations

  1. Use TLS in production — either native or via reverse proxy
  2. Use read-only credentials for public-facing access
  3. Rotate credentials regularly
  4. Set bucket quotas to prevent storage abuse
  5. Bind to localhost if only accessed locally (--host 127.0.0.1)
  6. Run as a non-root user — see the systemd guide for setup
  7. Use a firewall to restrict access to the S3 port
Raspberry Pi