Which connector?: AWS S3   Support Case Ref # #431377

Additional details:When configuring an Amazon S3 target location in HVR with a KMS Customer Master Key ID, the location defaults to (and silently remains on) Client-Side with KMS encryption, even when the customer's intent and bucket policy require Server-Side with KMS (SSE-KMS) encryption. There is no clear UI safeguard, validation, or warning that specifying a KMS Key ID alone does not enable server-side encryption — the separate S3_Encryption_SSE_KMS=true flag must also be explicitly set, and this requirement is not obvious from the Location Properties UI shown to the end user.

Background / Evidence from Support Case

• Customer's working production IAM user (dna_mad-qlik_prod_svc) was confirmed functional in another replication tool (Qlik) writing to the same S3 bucket/prefix, using Server-Side KMS encryption.
• When the same credentials were used in HVR against the same bucket, the write failed with: AccessDenied ... User: arn:aws:iam::029377893086:user/dna_mad-qlik_prod_svc is not authorized to perform: s3:PutObject on resource "arn:aws:s3:::psoft-sales-db2-prod-archival/test/PSF8TEST/ps_tm_query_rpt/" because no identity-based policy allows the s3:PutObject action.
• Investigation revealed the only material difference between the working tool (Qlik) and HVR was the encryption mode:
  • Qlik: Server-Side KMS encryption.
  • HVR: Client-Side with KMS (as shown in the Location Properties screenshot — "S3 Encryption" field set to "Client-Side with KMS" even though a KMS Customer Master Key ID and Region were populated).
• Fivetran Support confirmed that a KMS Key ID alone (without the S3_Encryption_SSE_KMS=true flag explicitly set) causes HVR to default to Client-Side KMS encryption rather than Server-Side SSE-KMS — a non-obvious behavior that is easy for customers to misconfigure, since the UI allows entering a KMS Key ID under multiple encryption modes without clearly differentiating the effective behavior.
• This mismatch in encryption mode is suspected to be a contributing factor in the authorization denial, since the bucket policy/KMS key policy may be scoped to expect server-side encryption headers (e.g., x-amz-server-side-encryption: aws:kms) that client-side encryption does not generate.

Impact

• Production cutover for the PSOFT DB2 Sales Archival bulk refresh (ps_tm_query_rpt) is blocked.
• Significant support cycle time spent (multiple days, several back-and-forth exchanges) to identify that the root cause/divergence was the client-side vs. server-side KMS encryption mode — a condition the UI does not clearly flag.
• Risk of recurrence for any other customer who populates a KMS Key ID expecting server-side encryption behavior, without realizing a second explicit flag (S3_Encryption_SSE_KMS) is required.

Requested Fix / Feature Enhancement

1. Update the HVR Location Properties UI so that entering a KMS Customer Master Key ID does not implicitly default to or remain on "Client-Side with KMS" — require explicit selection confirmation, or auto-prompt the user to choose between Client-Side KMS and Server-Side KMS when a key ID is provided.
2. Add inline UI guidance/tooltip clarifying that S3_Encryption_SSE_KMS=true must be explicitly enabled for Server-Side KMS encryption to take effect, and that a KMS Key ID alone does not determine server-side vs. client-side behavior.
3. Consider adding validation/warning at the channel level if the effective encryption mode (client-side vs. server-side) is detected to differ from a previously working configuration or from common AWS bucket-policy expectations (e.g., bucket policies that enforce s3:x-amz-server-side-encryption conditions).
4. Ensure exported location files and the properties UI clearly and consistently display the effective encryption mode, including whether S3_Encryption_SSE_KMS is set, so support and customers can diagnose this without multiple round trips.

Interim Ask

While this is evaluated for a future release, we request guidance/confirmation on the exact UI steps and parameter settings needed to reliably enable Server-Side KMS (S3_Encryption_SSE_KMS=true) in the current HVR version, and confirmation this change alone (with no folder change) should resolve the s3:PutObject AccessDenied error, since bucket-level policy and privileges are already confirmed identical across folders.