This PR enables to use the server side encryption on the s3() destination. It is a common pattern that data stored on the S3 bucket is encrypted at the rest.

S3 supports multiple server side encryption possibilities. This is only for the aws:kms method. In theory aws:kms:dsse should also work but as it uses the same arguments but I didn't test it so I disabled that intentionally.

Check the s3api documentation for the details.

This means that the server-side-encryption() option accepts only aws:kms or an empty string, which is the default.

The kms-key() should be:

• an ID of a key
• an alias of a key, but in that case you have to add the alias/ prefix
• an ARN of a key

For example:

destination d_s3 {
        s3(
                bucket( "log-archive-bucket" )
                object-key( "logs/syslog" )
                server-side-encryption( "aws:kms" )
                kms-key( "alias/log-archive" )
        );
};

To be able to use the aws:kms encryption the AWS Role or User has to have the following permissions on the given key:

• kms:Decrypt
• kms:Encrypt
• kms:GenerateDataKey

Check this page on why the kms:Decrypt is mandatory.

Setting server-side-encryption() to aws:kms without setting kms-key() will terminate the syslog-ng process.

Setting kms-key() without setting server-side-encryption() emits a warning and ignores the kms-key(). The server side encryption will be disabled in this case.

It also worth mentioning that kms-key() cannot be changed after the create_multipart_upload executed. I am not sure what will happen if someone modifies the key and then just reloads the syslog-ng configuration. A normal restart would work as syslog-ng finishes the multipart upload during the shutdown.