XKS architecture

the following diagram illustrates the high level architecture of an aws xks integration with {{ch}} , including connectivity options, certificate requirements, and authentication flows flowchart lr %% archbee compact xks overview (no parentheses in labels) subgraph aws\["aws account (region)"] kms\["aws kms (xks)"] end subgraph conn\["connectivity"] direction tb pub\["public endpoint (fqdn)"] pl\["aws privatelink"] end subgraph cust\["your environment"] proxy\["xks proxy (you operate)"] hub\["cryptohub"] hub end %% main paths kms >|public| pub >|tls 443| proxy kms >|private| pl >|tls 443| proxy proxy >|xks api policy and crypto ops| hub %% security notes for kms < > proxy tls cert\["server tls"] note mtls\["mtls (aws client cert)"] optional sigv4\["sigv4 dedicated credential"] note tls ver\["tls >= 1 2, aes gcm"] note tls cert > kms tls cert > proxy sigv4 > kms sigv4 > proxy tls ver > kms tls ver > proxy mtls > kms %% styles classdef note fill #eef6ff,stroke #2563eb,color #1e3a8a; classdef optional fill #fff7ed,stroke #f59e0b,color #7c2d12; classdef hub fill #fee2e2,stroke #dc2626,color #7f1d1d,font weight\ bold; component and flow explanation the preceding diagram shows the full architecture for integrating aws kms external key store (xks) with {{futurex}} {{ch}} , highlighting both connectivity options and the security requirements for each link aws kms (xks) aws key management service (kms) is operating in external key store mode, which means cryptographic keys are not stored inside aws instead, kms requests encryption and decryption services from an external key manager—in this case, {{ch}} —by using an xks proxy that you operate connectivity options you can connect aws kms to your xks proxy in the following ways public endpoint the proxy is reachable over the internet through a publicly resolvable fqdn a publicly trusted ca from aws’s approved list must issue the server tls certificate installed on the proxy the common name (cn) or subject alternative name (san) of the certificate must exactly match the hostname you configure in aws (xksproxyuriendpoint) a full certificate chain must be presented aws privatelink the proxy is exposed as an aws vpc endpoint service aws privatelink uses a private dns hostname you define, and your tls certificate must match that private dns name this option avoids exposure to the public internet but requires an aws networking setup (vpc endpoint service, nlb, target groups, and health checks) in either case, traffic between kms and the proxy must be encrypted with tls, and aws only supports ipv4 over tcp port 443 security for the kms ⇄ proxy link you can use the following methods for the kms to proxy link server tls keep the following considerations in mind a public ca from aws’s trusted list must issue the tls certificate cn or san must match the endpoint (public or privatelink dns name) must present a complete certificate chain protocols tls 1 2 or higher cipher suites must be strong, such as the following options tls 1 3 tls aes 256 gcm sha384, tls chacha20 poly1305 sha256 tls 1 2 tls ecdhe rsa with aes 256 gcm sha384, tls ecdhe ecdsa with aes 256 gcm sha384 mutual tls (optional) keep the following considerations in mind if enabled, aws kms presents a client tls certificate the cn for the client certificate is cks kms \<region> amazonaws com (for example, cks kms us east 1 amazonaws com ) the certificate chain terminates at an amazon trust services ca if you enable mtls, you must configure your proxy to accept only these aws issued client certificates sigv4 authentication keep the following considerations in mind aws signature version 4 signs every request from aws kms to your proxy you must configure kms with an accesskeyid and secretaccesskey pair that your proxy validates this credential must be dedicated to the xks proxy —do not reuse an iam access key or any credential used for other purposes plan for credential rotation update the proxy first, then update the external key store in kms with the new pair tls requirements keep the following considerations in mind minimum protocol tls 1 2 only approved cipher suites are allowed (see the preceding server and mutual tls sections) only ipv4 is supported, and the port must be 443 xks proxy (you operate) the proxy is a web service that implements the xks proxy api validates aws sigv4 requests and, if enabled, the aws client tls certificate translates aws kms api calls into requests to your external key manager returns results to kms, never exposing the raw key material performance expectations aws recommends the proxy handle 1,800 requests/sec target a maximum 250ms latency for proxy responses, as delays directly affect aws service encryption/decryption performance {{ch}} {{ch}} offers the following advantages acts as the external key manager behind the proxy stores and protects your encryption keys inside a certified hsm enforces your organization’s key access and usage policies responds to the proxy requests for operations like generatedatakey , encrypt , and decrypt operational notes availability if your proxy or cryptohub is unavailable, aws kms cannot perform new encrypt/decrypt operations with external keys only aws services that have cached a data key can continue until the cache expires monitoring use aws cloudwatch metrics like xksproxyerrors to detect proxy failures quotas kms api request limits apply to xks plan capacity accordingly testing before creating the external key store in aws, validate your proxy with aws’s xks proxy test client to ensure tls, mtls, sigv4, and api compatibility if you want, i can also create a “quick reference table” to put directly after this explanation, summarizing all the certificate, networking, and authentication requirements in one glance that works really well for teams doing the actual setup would you like me to prepare that?