Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

このコンテンツは選択した言語では利用できません。

Chapter 3. Configuring the Record Encryption filter

This section describes at a high level how to configure the Record Encryption filter using a previously prepared KMS. Subsections provide in-depth details.

Prerequisites

Procedure

  1. Configure the plugin for your supported KMS, as required.

  2. Create a filter configuration that references the configured KMS plugins.

    See Section 3.4, “Filter configuration”

  3. Apply the filter configuration:

3.1. HashiCorp Vault plugin configuration
リンクのコピー

For HashiCorp Vault, the KMS configuration used by the filter looks like this. Use the Vault Token and Vault Transit Engine URL values from the KMS setup. 

kms: VaultKmsService
1 

kmsConfig:
  vaultTransitEngineUrl: <vault transit engine service url>
2 

  tls:
3 

    # ...
  vaultToken:
4 

    passwordFile: /opt/vault/token
Copy to Clipboard Toggle word wrap
1
Specifies the name of the KMS provider. Use VaultKmsService.
2
Vault Transit Engine URL including the protocol part, such as https: or http:.
3
(Optional) TLS trust configuration.
4
File containing the Vault Token.

A TLS client certificate can be specified using a PKCS#12 or JKS key store file.

Example TLS client certificate configuration using a PKCS#12 key store file

key:
  storeFile: /opt/cert/server.p12
1 

  storeType: PKCS12
2 

  storePassword:
3 

    passwordFile: /opt/cert/store.password
  keyPassword:
4 

    passwordFile: /opt/cert/key.password
Copy to Clipboard Toggle word wrap

1
storeFile specifies PKCS#12 file
2
storeType specifies what the keystore file type is. Supported values include PKCS12 and JKS.
3
Optionally, a keystore file password may be specified.
4
Optionally, a password may be specified for the key entry within the file.

A set of trust anchors for the TLS client can be specified using a PKCS#12 or JKS key store file.

Example TLS client trust change configuration using a PKCS#12 key store file

trust:
  storeFile: /opt/cert/server.p12
1 

  storeType: PKCS12
2 

  storePassword:
3 

    passwordFile: /opt/cert/store.password
Copy to Clipboard Toggle word wrap

1
storeFile specifies PKCS#12 file
2
storeType specifies what the keystore file type is. Supported values include PKCS12 and JKS.
3
Optionally, a keystore file password may be specified.

3.2. AWS KMS plugin configuration
リンクのコピー

For AWS KMS the configuration for authenticating with AWS KMS services looks like this:

Configuration for authenticating with a long-term IAM identity

kms: AwsKmsService
1 

kmsConfig:
  endpointUrl: https://kms.<region>.amazonaws.com
2 

  tls:
3 

    # ...
  longTermCredentials:
    accessKeyId:
      passwordFile: /opt/aws/accessKey
4 

    secretAccessKey:
      passwordFile: /opt/aws/secretKey
5 

  region: <region>
6
Copy to Clipboard Toggle word wrap

1
Specifies the name of the KMS provider. Use AwsKmsService.
2
AWS KMS endpoint URL, which must include the https:// scheme.
3
(Optional) TLS trust configuration.
4
File containing the AWS access key ID.
5
File containing the AWS secret access key.
6
The AWS region identifier, such as us-east-1, specifying where your KMS resources are located. This must match the region of the KMS endpoint you’re using.

A TLS client certificate can be specified using a PKCS#12 or JKS key store file.

Example TLS client certificate configuration using a PKCS#12 key store file

key:
  storeFile: /opt/cert/server.p12
1 

  storeType: PKCS12
2 

  storePassword:
3 

    passwordFile: /opt/cert/store.password
  keyPassword:
4 

    passwordFile: /opt/cert/key.password
Copy to Clipboard Toggle word wrap

1
storeFile specifies PKCS#12 file
2
storeType specifies what the keystore file type is. Supported values include PKCS12 and JKS.
3
Optionally, a keystore file password may be specified.
4
Optionally, a password may be specified for the key entry within the file.

A set of trust anchors for the TLS client can be specified using a PKCS#12 or JKS key store file.

Example TLS client trust change configuration using a PKCS#12 key store file

trust:
  storeFile: /opt/cert/server.p12
1 

  storeType: PKCS12
2 

  storePassword:
3 

    passwordFile: /opt/cert/store.password
Copy to Clipboard Toggle word wrap

1
storeFile specifies PKCS#12 file
2
storeType specifies what the keystore file type is. Supported values include PKCS12 and JKS.
3
Optionally, a keystore file password may be specified.

3.3. Azure Key Vault plugin configuration
リンクのコピー

For Azure Key Vault the configuration for authenticating with Microsoft Identity Platform looks like this:

Configuration for authenticating with Microsoft Identity Platform via OAuth 2.0

kms: AzureKeyVault
kmsConfig:
  keyVaultName: my-key-vault
  keyVaultHost: vault.azure.net
  tls:
    # ... client trust configuration for Azure Key Vault
  oauth2ClientCredentials:
    oauthEndpoint: https://login.microsoftonline.com
    tenantId: "00000000-0000-0000-0000-000000000000"
    clientId:
      passwordFile: /path/to/id
    clientSecret:
      passwordFile: /path/to/secret
    scope: https://vault.azure.net/.default
    tls:
      # ... client trust configuration for Microsoft Identity Platform OAuth2
Copy to Clipboard Toggle word wrap

  • kms specifies the name of the KMS provider. Use AzureKeyVault.
  • keyVaultName is the name of the key vault the filter uses.
  • keyVaultHost is the key vault host name, without the key vault name prefix.
  • oauthEndpoint is the URL used for the OAuth 2.0 Client Credentials flow.
  • tenantId is the 32-character identifier for the Microsoft Entra tenant where the OAuth credentials were created.
  • clientId.passwordFile specifies the file that contains the OAuth client ID.
  • clientSecret.passwordFile specifies the file that contains the OAuth client secret.
  • scope is the App ID URI of the target resource that the proxy authenticates to (your Azure Key Vault URI).

A TLS client certificate can be specified using a PKCS#12 or JKS key store file.

Example TLS client certificate configuration using a PKCS#12 key store file

key:
  storeFile: /opt/cert/server.p12
1 

  storeType: PKCS12
2 

  storePassword:
3 

    passwordFile: /opt/cert/store.password
  keyPassword:
4 

    passwordFile: /opt/cert/key.password
Copy to Clipboard Toggle word wrap

1
storeFile specifies PKCS#12 file
2
storeType specifies what the keystore file type is. Supported values include PKCS12 and JKS.
3
Optionally, a keystore file password may be specified.
4
Optionally, a password may be specified for the key entry within the file.

A set of trust anchors for the TLS client can be specified using a PKCS#12 or JKS key store file.

Example TLS client trust change configuration using a PKCS#12 key store file

trust:
  storeFile: /opt/cert/server.p12
1 

  storeType: PKCS12
2 

  storePassword:
3 

    passwordFile: /opt/cert/store.password
Copy to Clipboard Toggle word wrap

1
storeFile specifies PKCS#12 file
2
storeType specifies what the keystore file type is. Supported values include PKCS12 and JKS.
3
Optionally, a keystore file password may be specified.

3.4. Filter configuration
リンクのコピー

This procedure describes how to configure the Record Encryption filter. Provide the filter configuration and the Key Encryption Key (KEK) selector to use. The KEK selector maps topic name to key names. The filter looks up the resulting key name in the KMS.

Prerequisites

Procedure

  1. Configure a RecordEncryption type filter.

    Example Record Encryption filter configuration

    kms: <kms_service_name>
    1 
    
kmsConfig:
  <kms_specific_config>
    2 
    
  # ...
selector: <KEK-selector_service_name>
    3 
    
selectorConfig:
  template: "KEK-$(topicName)"
    4 
    
unresolvedKeyPolicy: PASSTHROUGH_UNENCRYPTED
    5 
    
experimental:
  encryptionDekRefreshAfterWriteSeconds: 3600
    6 
    
  encryptionDekExpireAfterWriteSeconds: 7200
    7 
    
  maxEncryptionsPerDek: 5000000
    8
    Copy to Clipboard Toggle word wrap

    1
    The KMS service name.
    2
    Configuration specific to the KMS provider.
    3
    The Key Encryption Key (KEK) selector to use. The $(topicName) is a literal understood by the proxy. For example, if using the TemplateKekSelector with the template KEK-$(topicName), create a key for every topic that is to be encrypted with the key name matching the topic name, prefixed by the string KEK-.
    4
    The template for deriving the KEK, based on a specific topic name.
    5
    Optional policy governing the behaviour when the KMS does not contain a key. The default is PASSTHROUGH_UNENCRYPTED which causes the record to be forwarded, unencrypted, to the target cluster. Users can alternatively specify REJECT which will cause the entire produce request to be rejected. This is a safer alternative if you know that all traffic sent to the Virtual Cluster should be encrypted because unencrypted data will never be forwarded.
    6
    How long after creation of a DEK before it becomes eligible for rotation. On the next encryption request, the cache will asynchronously create a new DEK. Encryption requests will continue to use the old DEK until the new DEK is ready.
    7
    How long after creation of a DEK until it is removed from the cache. This setting puts an upper bound on how long a DEK can remain cached.
    8
    The maximum number of records any DEK should be used to encrypt. After this limit is hit, that DEK will be destroyed and a new one created.

    encryptionDekRefreshAfterWriteSeconds and encryptionDekExpireAfterWriteSeconds properties govern the originator usage period of the DEK, which is the amount of time the DEK remains valid for encrypting records. Shortening this period helps limit the impact if the DEK key material is leaked. However, shorter periods increase the number of KMS API calls, which might affect produce and consume latency and raise KMS provider costs.

    maxEncryptionsPerDek helps prevent key exhaustion by placing an upper limit of the amount of times that a DEK may be used to encrypt records.

  2. Verify that the encryption has been applied to the specified topics by producing messages through the proxy and then consuming directly and indirectly from the Kafka cluster.
Note

If the filter is unable to find the key in the KMS, the filter passes through the records belonging to that topic in the produce request without encrypting them.

3.5. Example KafkaProtocolFilter resource
リンクのコピー

If your instance of Streams for Apache Kafka Proxy runs on OpenShift, you must use a KafkaProtocolFilter resource to contain the filter configuration.

Here’s a complete example of a KafkaProtocolFilter resource configured for record encryption with Vault KMS:

Example KafkaProtocolFilter resource

kind: KafkaProtocolFilter
metadata:
  name: my-encryption-filter
spec:
  type: RecordEncryption
  configTemplate:
    kms: VaultKmsService
    kmsConfig:
      vaultTransitEngineUrl: # ...
      tls: # ...
      vaultToken:
        passwordFile: ${secret:encryption-filter:vault-token}
    selector: TemplateKekSelector
    selectorConfig:
      template: "KEK-$(topicName)"
    unresolvedKeyPolicy: PASSTHROUGH_UNENCRYPTED
    experimental:
      encryptionDekRefreshAfterWriteSeconds: 3600
      encryptionDekExpireAfterWriteSeconds: 7200
      maxEncryptionsPerDek: 5000000
Copy to Clipboard Toggle word wrap

Refer to the Deploying and Managing Streams for Apache Kafka Proxy on OpenShift guide for more information about configuration on OpenShift.

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hatトップに戻る