Encryption

OBSESC encrypts everything it stores with a customer-managed KMS key that you own. It can also encrypt its network listeners with TLS certificates you supply. This page explains what is encrypted, with which key, and what you need to configure.

At rest

When you launch the stack, you pass one key as KmsKeyArn. It is used for:

Data	Where	How
Root volume	EBS	EBS encryption with KmsKeyArn
Data volumes (incoming data and OBSESC’s working data)	EBS	EBS encryption with KmsKeyArn
Daily snapshots of the data volumes	EBS snapshots	Inherit the source volumes’ encryption
Raw events, catalog, audit trail, legal holds	S3 raw bucket	SSE-KMS requested on every write

S3 writes

The node requests aws:kms server-side encryption with your key on every upload to the raw bucket. The stack sets this for you:

storage:
  s3_bucket: "my-obsesc-bucket"
  s3_sse_kms_key_arn: "arn:aws:kms:us-east-1:111122223333:key/<key-id>"

If the key is unset, objects are encrypted with the bucket’s default encryption instead.

When the stack creates the bucket (CreateRawBucket=true), it also:

• sets default encryption to SSE-KMS with your key and turns on the S3 Bucket Key
• blocks all public access
• keeps the bucket when the stack is deleted

If you bring your own bucket, set equivalent protections on it yourself.

What your key policy must allow

The node role’s IAM policy grants it kms:Encrypt, Decrypt, GenerateDataKey and DescribeKey on your key. A customer-managed key only honours IAM grants if the key policy allows it, either by delegating to IAM in your account or by naming the roles directly. Check each case that applies to you:

• Node role: the four actions above.
• Snapshot role (created when EnableDataVolumeSnapshots=true, the default): kms:CreateGrant, Decrypt, DescribeKey, GenerateDataKeyWithoutPlaintext, ReEncryptFrom, ReEncryptTo. IAM alone isn’t enough here. If your key policy doesn’t allow the Data Lifecycle Manager role, snapshots of your encrypted volumes will fail.
• Cross-account raw bucket: if the bucket account encrypts with its own key, that key’s policy must allow your node role the four node-role actions.

For multi-node deployments, contact us for the additional key-policy grants.

Local secret files

Secrets that must exist on disk are written with restricted permissions at first boot:

File	Contents	Permissions
/etc/obsesc/tls/cert.pem, key.pem	TLS material read from SSM SecureString	0400, readable only by the node’s service user
/etc/obsesc/alb-oidc-key.pem	The load balancer’s public signing key (not a secret)	0640

Ingest and API tokens from Secrets Manager are held in memory and aren’t written to the config file.

In transit

Node listeners

Turn on TLS and the OTLP (gRPC and HTTP), Elasticsearch _bulk, Splunk HEC, Fluent Forward, Vector, Loki and Firehose listeners, GELF over TCP, and the console and query API port serve TLS only. The same port has no plaintext fallback. GELF over UDP can’t use TLS.

With the stack, supply the certificate chain and private key as two SSM SecureString parameters:

aws ssm put-parameter --name /obsesc/tls/cert --type SecureString --value file://fullchain.pem
aws ssm put-parameter --name /obsesc/tls/key  --type SecureString --value file://privkey.pem

Then launch with TlsCertSsmParameter=/obsesc/tls/cert and TlsKeySsmParameter=/obsesc/tls/key. The node config then contains:

security:
  tls:
    cert_path: /etc/obsesc/tls/cert.pem
    key_path: /etc/obsesc/tls/key.pem

The certificate must be a PEM chain with the leaf first. The key can be PKCS#8 or RSA. The node accepts TLS 1.2 and TLS 1.3. Without TLS, the listeners serve plaintext and the node warns at startup. Plaintext is only suitable for a private network where you’ve accepted that risk.

After turning on TLS, change your shippers to use https:// (or TLS on the Forward and gRPC outputs). They must trust the certificate’s issuer.

Certificate rotation

By default, the node reads certificates once, at startup. To rotate them without a restart, set a reload interval:

security:
  tls:
    cert_path: /etc/obsesc/tls/cert.pem
    key_path: /etc/obsesc/tls/key.pem
    reload_interval_secs: 3600

The node re-reads the files on that interval and swaps them in. If the new certificate doesn’t parse or doesn’t match its key, the node keeps serving the old one. Reloading covers the HTTP listeners (including the console and query API) and the TCP listeners such as Fluent Forward. It doesn’t cover the gRPC listeners (OTLP/gRPC and Vector), which keep the certificate they loaded at startup, so restart the node before the old certificate expires.

Console and load balancer

The optional internal ALB terminates HTTPS on 443 (and 8443 when EnableNodeApiOidc is on) using your ACM certificate and the ELBSecurityPolicy-TLS13-1-2-2021-06 policy. Plain HTTP on port 80 redirects to HTTPS. Between the ALB and the node, traffic goes to port 18080 inside your VPC, over HTTPS when the node has TLS configured and over HTTP otherwise.

AWS API calls

Calls to S3, KMS, STS, Secrets Manager and SSM use the AWS SDK over HTTPS.

Related

• Security model
• Network configuration
• Configuration reference