A unique identifier for this DeleteStack request. Specify this token if you plan to retry requests\n so that CloudFormation knows that you're not attempting to delete a stack with the same name. You might retry\n DeleteStack requests to ensure that CloudFormation successfully received them.
All events initiated by a given stack operation are assigned the same client request token, which you can use to\n track operations. For example, if you execute a CreateStack operation with the token\n token1, then all the StackEvents generated by that operation will have\n ClientRequestToken set as token1.
In the console, stack operations display the client request token on the Events tab. Stack operations that are\n initiated from the console use the token format Console-StackOperation-ID, which helps you\n easily identify the stack operation . For example, if you create a stack using the console, each stack event would be\n assigned the same token in the following format:\n Console-CreateStack-7f59c3cf-00d2-40c7-b2ff-e75db0987002.
Specifies the deletion mode for the stack. Possible values are:
\n\n STANDARD - Use the standard behavior. Specifying this value is the same as not specifying this\n parameter.
\n FORCE_DELETE_STACK - Delete the stack if it's stuck in a DELETE_FAILED state due to\n resource deletion failure.
A list of StackInstanceResourceDriftSummary structures that contain information about the specified\n stack instances.
A list of StackInstanceResourceDriftsSummary structures that contain information about the\n specified stack instances.
When set to true, newly created resources are deleted when the operation rolls back. This includes\n newly created resources marked with a deletion policy of Retain.
Default: false\n
Specifies the deletion mode for the stack. Possible values are:
\n\n STANDARD - Use the standard behavior. Specifying this value is the same as not specifying this\n parameter.
\n FORCE_DELETE_STACK - Delete the stack if it's stuck in a DELETE_FAILED state due to\n resource deletion failure.
Specifies how the concurrency level behaves during the operation execution.
\n\n STRICT_FAILURE_TOLERANCE: This option dynamically lowers the concurrency level to ensure the\n number of failed accounts never exceeds the value of FailureToleranceCount +1. The initial actual\n concurrency is set to the lower of either the value of the MaxConcurrentCount, or the value of\n MaxConcurrentCount +1. The actual concurrency is then reduced proportionally by the number of\n failures. This is the default behavior.
If failure tolerance or Maximum concurrent accounts are set to percentages, the behavior is similar.
\n\n SOFT_FAILURE_TOLERANCE: This option decouples FailureToleranceCount from the actual\n concurrency. This allows stack set operations to run at the concurrency level set by the\n MaxConcurrentCount value, or MaxConcurrentPercentage, regardless of the number of\n failures.
Specifies how the concurrency level behaves during the operation execution.
\n\n STRICT_FAILURE_TOLERANCE: This option dynamically lowers the concurrency level to ensure the\n number of failed accounts never exceeds the value of FailureToleranceCount +1. The initial actual\n concurrency is set to the lower of either the value of the MaxConcurrentCount, or the value of\n FailureToleranceCount +1. The actual concurrency is then reduced proportionally by the number of\n failures. This is the default behavior.
If failure tolerance or Maximum concurrent accounts are set to percentages, the behavior is similar.
\n\n SOFT_FAILURE_TOLERANCE: This option decouples FailureToleranceCount from the actual\n concurrency. This allows stack set operations to run at the concurrency level set by the\n MaxConcurrentCount value, or MaxConcurrentPercentage, regardless of the number of\n failures.
Returns the public key and an import token you need to import or reimport key material for\n a KMS key.
\nBy default, KMS keys are created with key material that KMS generates. This operation\n supports Importing key\n material, an advanced feature that lets you generate and import the cryptographic\n key material for a KMS key. For more information about importing key material into KMS, see\n Importing key\n material in the Key Management Service Developer Guide.
\nBefore calling GetParametersForImport, use the CreateKey\n operation with an Origin value of EXTERNAL to create a KMS key with\n no key material. You can import key material for a symmetric encryption KMS key, HMAC KMS key,\n asymmetric encryption KMS key, or asymmetric signing KMS key. You can also import key material\n into a multi-Region key of any supported type. However, you can't import key material into\n a KMS key in a custom key store. You can also use GetParametersForImport to get a\n public key and import token to reimport the original key\n material into a KMS key whose key material expired or was deleted.
\n GetParametersForImport returns the items that you need to import your key\n material.
The public key (or \"wrapping key\") of an RSA key pair that KMS generates.
\nYou will use this public key to encrypt (\"wrap\") your key material while it's in\n transit to KMS.
\nA import token that ensures that KMS can decrypt your key material and associate it\n with the correct KMS key.
\nThe public key and its import token are permanently linked and must be used together. Each\n public key and import token set is valid for 24 hours. The expiration date and time appear in\n the ParametersValidTo field in the GetParametersForImport response.\n You cannot use an expired public key or import token in an ImportKeyMaterial\n request. If your key and token expire, send another GetParametersForImport\n request.
\n GetParametersForImport requires the following information:
The key ID of the KMS key for which you are importing the key material.
\nThe key spec of the public key (\"wrapping key\") that you will use to encrypt your key\n material during import.
\nThe wrapping algorithm that you will use with the public key to encrypt your key\n material.
\nYou can use the same or a different public key spec and wrapping algorithm each time you\n import or reimport the same key material.
\nThe KMS key that you use for this operation must be in a compatible key state. For\ndetails, see Key states of KMS keys in the Key Management Service Developer Guide.
\n\n Cross-account use: No. You cannot perform this operation on a KMS key in a different Amazon Web Services account.
\n\n Required permissions: kms:GetParametersForImport (key policy)
\n\n Related operations:\n
\n\n ImportKeyMaterial\n
\n\n Eventual consistency: The KMS API follows an eventual consistency model. \n For more information, see KMS eventual consistency.
" + "smithy.api#documentation": "Returns the public key and an import token you need to import or reimport key material for\n a KMS key.
\nBy default, KMS keys are created with key material that KMS generates. This operation\n supports Importing key\n material, an advanced feature that lets you generate and import the cryptographic\n key material for a KMS key. For more information about importing key material into KMS, see\n Importing key\n material in the Key Management Service Developer Guide.
\nBefore calling GetParametersForImport, use the CreateKey\n operation with an Origin value of EXTERNAL to create a KMS key with\n no key material. You can import key material for a symmetric encryption KMS key, HMAC KMS key,\n asymmetric encryption KMS key, or asymmetric signing KMS key. You can also import key material\n into a multi-Region key of any supported type. However, you can't import key material into\n a KMS key in a custom key store. You can also use GetParametersForImport to get a\n public key and import token to reimport the original key\n material into a KMS key whose key material expired or was deleted.
\n GetParametersForImport returns the items that you need to import your key\n material.
The public key (or \"wrapping key\") of an asymmetric key pair that KMS generates.
\nYou will use this public key to encrypt (\"wrap\") your key material while it's in\n transit to KMS.
\nA import token that ensures that KMS can decrypt your key material and associate it\n with the correct KMS key.
\nThe public key and its import token are permanently linked and must be used together. Each\n public key and import token set is valid for 24 hours. The expiration date and time appear in\n the ParametersValidTo field in the GetParametersForImport response.\n You cannot use an expired public key or import token in an ImportKeyMaterial\n request. If your key and token expire, send another GetParametersForImport\n request.
\n GetParametersForImport requires the following information:
The key ID of the KMS key for which you are importing the key material.
\nThe key spec of the public key (\"wrapping key\") that you will use to encrypt your key\n material during import.
\nThe wrapping algorithm that you will use with the public key to encrypt your key\n material.
\nYou can use the same or a different public key spec and wrapping algorithm each time you\n import or reimport the same key material.
\nThe KMS key that you use for this operation must be in a compatible key state. For\ndetails, see Key states of KMS keys in the Key Management Service Developer Guide.
\n\n Cross-account use: No. You cannot perform this operation on a KMS key in a different Amazon Web Services account.
\n\n Required permissions: kms:GetParametersForImport (key policy)
\n\n Related operations:\n
\n\n ImportKeyMaterial\n
\n\n Eventual consistency: The KMS API follows an eventual consistency model. \n For more information, see KMS eventual consistency.
" } }, "com.amazonaws.kms#GetParametersForImportRequest": { @@ -3597,14 +3603,14 @@ "WrappingAlgorithm": { "target": "com.amazonaws.kms#AlgorithmSpec", "traits": { - "smithy.api#documentation": "The algorithm you will use with the RSA public key (PublicKey) in the\n response to protect your key material during import. For more information, see Select a wrapping algorithm in the Key Management Service Developer Guide.
For RSA_AES wrapping algorithms, you encrypt your key material with an AES key that you\n generate, then encrypt your AES key with the RSA public key from KMS. For RSAES wrapping\n algorithms, you encrypt your key material directly with the RSA public key from KMS.
\nThe wrapping algorithms that you can use depend on the type of key material that you are\n importing. To import an RSA private key, you must use an RSA_AES wrapping algorithm.
\n\n RSA_AES_KEY_WRAP_SHA_256 — Supported for\n wrapping RSA and ECC key material.
\n\n RSA_AES_KEY_WRAP_SHA_1 — Supported for\n wrapping RSA and ECC key material.
\n\n RSAES_OAEP_SHA_256 — Supported for all types\n of key material, except RSA key material (private key).
\nYou cannot use the RSAES_OAEP_SHA_256 wrapping algorithm with the RSA_2048 wrapping\n key spec to wrap ECC_NIST_P521 key material.
\n\n RSAES_OAEP_SHA_1 — Supported for all types of\n key material, except RSA key material (private key).
\nYou cannot use the RSAES_OAEP_SHA_1 wrapping algorithm with the RSA_2048 wrapping key\n spec to wrap ECC_NIST_P521 key material.
\n\n RSAES_PKCS1_V1_5 (Deprecated) — As of October\n 10, 2023, KMS does not support the RSAES_PKCS1_V1_5 wrapping algorithm.
\nThe algorithm you will use with the asymmetric public key (PublicKey) in the\n response to protect your key material during import. For more information, see Select a wrapping algorithm in the Key Management Service Developer Guide.
For RSA_AES wrapping algorithms, you encrypt your key material with an AES key that you\n generate, then encrypt your AES key with the RSA public key from KMS. For RSAES wrapping\n algorithms, you encrypt your key material directly with the RSA public key from KMS. \n For SM2PKE wrapping algorithms, you encrypt your key material directly with the SM2 public key \n from KMS.
\nThe wrapping algorithms that you can use depend on the type of key material that you are\n importing. To import an RSA private key, you must use an RSA_AES wrapping algorithm, except \n in China Regions, where you must use the SM2PKE wrapping algorithm to import an RSA private key.
\nThe SM2PKE wrapping algorithm is available only in China Regions. The \n RSA_AES_KEY_WRAP_SHA_256 and RSA_AES_KEY_WRAP_SHA_1 \n wrapping algorithms are not supported in China Regions.
\n RSA_AES_KEY_WRAP_SHA_256 — Supported for\n wrapping RSA and ECC key material.
\n\n RSA_AES_KEY_WRAP_SHA_1 — Supported for\n wrapping RSA and ECC key material.
\n\n RSAES_OAEP_SHA_256 — Supported for all types\n of key material, except RSA key material (private key).
\nYou cannot use the RSAES_OAEP_SHA_256 wrapping algorithm with the RSA_2048 wrapping\n key spec to wrap ECC_NIST_P521 key material.
\n\n RSAES_OAEP_SHA_1 — Supported for all types of\n key material, except RSA key material (private key).
\nYou cannot use the RSAES_OAEP_SHA_1 wrapping algorithm with the RSA_2048 wrapping key\n spec to wrap ECC_NIST_P521 key material.
\n\n RSAES_PKCS1_V1_5 (Deprecated) — As of October\n 10, 2023, KMS does not support the RSAES_PKCS1_V1_5 wrapping algorithm.
\n\n SM2PKE (China Regions only) — supported for \n wrapping RSA, ECC, and SM2 key material.
\nThe type of RSA public key to return in the response. You will use this wrapping key with\n the specified wrapping algorithm to protect your key material during import.
\nUse the longest RSA wrapping key that is practical.
\nYou cannot use an RSA_2048 public key to directly wrap an ECC_NIST_P521 private key.\n Instead, use an RSA_AES wrapping algorithm or choose a longer RSA public key.
", + "smithy.api#documentation": "The type of public key to return in the response. You will use this wrapping key with\n the specified wrapping algorithm to protect your key material during import.
\nUse the longest wrapping key that is practical.
\nYou cannot use an RSA_2048 public key to directly wrap an ECC_NIST_P521 private key.\n Instead, use an RSA_AES wrapping algorithm or choose a longer RSA public key.
\nThe SM2 wrapping key spec is available only in China Regions.
", "smithy.api#required": {} } } @@ -9166,6 +9172,12 @@ "traits": { "smithy.api#enumValue": "RSA_4096" } + }, + "SM2": { + "target": "smithy.api#Unit", + "traits": { + "smithy.api#enumValue": "SM2" + } } } }, diff --git a/codegen/sdk-codegen/aws-models/opensearch.json b/codegen/sdk-codegen/aws-models/opensearch.json index 078f76fc48a..13ebaae8f55 100644 --- a/codegen/sdk-codegen/aws-models/opensearch.json +++ b/codegen/sdk-codegen/aws-models/opensearch.json @@ -3669,6 +3669,12 @@ "traits": { "smithy.api#documentation": "A description of the data source.
" } + }, + "Status": { + "target": "com.amazonaws.opensearch#DataSourceStatus", + "traits": { + "smithy.api#documentation": "The status of the data source.
" + } } }, "traits": { @@ -3691,6 +3697,23 @@ "smithy.api#pattern": "^[a-z][a-z0-9_]+$" } }, + "com.amazonaws.opensearch#DataSourceStatus": { + "type": "enum", + "members": { + "ACTIVE": { + "target": "smithy.api#Unit", + "traits": { + "smithy.api#enumValue": "ACTIVE" + } + }, + "DISABLED": { + "target": "smithy.api#Unit", + "traits": { + "smithy.api#enumValue": "DISABLED" + } + } + } + }, "com.amazonaws.opensearch#DataSourceType": { "type": "union", "members": { @@ -6210,7 +6233,7 @@ "DomainEndpointV2HostedZoneId": { "target": "com.amazonaws.opensearch#HostedZoneId", "traits": { - "smithy.api#documentation": "The DualStack Hosted Zone Id for the domain.
" + "smithy.api#documentation": "The dual stack hosted zone ID for the domain.
" } }, "Processing": { @@ -6856,6 +6879,12 @@ "traits": { "smithy.api#documentation": "A description of the data source.
" } + }, + "Status": { + "target": "com.amazonaws.opensearch#DataSourceStatus", + "traits": { + "smithy.api#documentation": "The status of the data source response.
" + } } }, "traits": { @@ -11915,6 +11944,12 @@ "traits": { "smithy.api#documentation": "A new description of the data source.
" } + }, + "Status": { + "target": "com.amazonaws.opensearch#DataSourceStatus", + "traits": { + "smithy.api#documentation": "The status of the data source update request.
" + } } }, "traits": { diff --git a/codegen/sdk-codegen/aws-models/wafv2.json b/codegen/sdk-codegen/aws-models/wafv2.json index fcf56f5884c..a1d41b158cd 100644 --- a/codegen/sdk-codegen/aws-models/wafv2.json +++ b/codegen/sdk-codegen/aws-models/wafv2.json @@ -1901,7 +1901,7 @@ "SearchString": { "target": "com.amazonaws.wafv2#SearchString", "traits": { - "smithy.api#documentation": "A string value that you want WAF to search for. WAF searches only in the part of\n web requests that you designate for inspection in FieldToMatch. The\n maximum length of the value is 200 bytes.
\nValid values depend on the component that you specify for inspection in\n FieldToMatch:
\n Method: The HTTP method that you want WAF to search for. This\n indicates the type of operation specified in the request.
\n UriPath: The value that you want WAF to search for in the URI path,\n for example, /images/daily-ad.jpg.
\n JA3Fingerprint: Match against the request's JA3 fingerprint. The JA3 fingerprint is a 32-character hash derived from the TLS Client Hello of an incoming request. This fingerprint serves as a unique identifier for the client's TLS configuration. You can use this choice only with a string match ByteMatchStatement with the PositionalConstraint set to \n EXACTLY.
You can obtain the JA3 fingerprint for client requests from the web ACL logs. \n\t\t\t\t\t\tIf WAF is able to calculate the fingerprint, it includes it in the logs. \n\t\t\t\t\t\tFor information about the logging fields, \nsee Log fields in the WAF Developer Guide.
\n\n HeaderOrder: The list of header names to match for. WAF creates a \n string that contains the ordered list of header names, from the headers in the web request, and then matches against that string.
If SearchString includes alphabetic characters A-Z and a-z, note that the\n value is case sensitive.
\n If you're using the WAF API\n
\nSpecify a base64-encoded version of the value. The maximum length of the value before\n you base64-encode it is 200 bytes.
\nFor example, suppose the value of Type is HEADER and the value\n of Data is User-Agent. If you want to search the\n User-Agent header for the value BadBot, you base64-encode\n BadBot using MIME base64-encoding and include the resulting value,\n QmFkQm90, in the value of SearchString.
\n If you're using the CLI or one of the Amazon Web Services SDKs\n
\nThe value that you want WAF to search for. The SDK automatically base64 encodes the\n value.
", + "smithy.api#documentation": "A string value that you want WAF to search for. WAF searches only in the part of\n web requests that you designate for inspection in FieldToMatch. The\n maximum length of the value is 200 bytes.
\nValid values depend on the component that you specify for inspection in\n FieldToMatch:
\n Method: The HTTP method that you want WAF to search for. This\n indicates the type of operation specified in the request.
\n UriPath: The value that you want WAF to search for in the URI path,\n for example, /images/daily-ad.jpg.
\n JA3Fingerprint: Available for use with Amazon CloudFront distributions and Application Load Balancers. Match against the request's JA3 fingerprint. The JA3 fingerprint is a 32-character hash derived from the TLS Client Hello of an incoming request. This fingerprint serves as a unique identifier for the client's TLS configuration. You can use this choice only with a string match ByteMatchStatement with the PositionalConstraint set to \n EXACTLY.
You can obtain the JA3 fingerprint for client requests from the web ACL logs. \n\t\t\t\t\t\tIf WAF is able to calculate the fingerprint, it includes it in the logs. \n\t\t\t\t\t\tFor information about the logging fields, \nsee Log fields in the WAF Developer Guide.
\n\n HeaderOrder: The list of header names to match for. WAF creates a \n string that contains the ordered list of header names, from the headers in the web request, and then matches against that string.
If SearchString includes alphabetic characters A-Z and a-z, note that the\n value is case sensitive.
\n If you're using the WAF API\n
\nSpecify a base64-encoded version of the value. The maximum length of the value before\n you base64-encode it is 200 bytes.
\nFor example, suppose the value of Type is HEADER and the value\n of Data is User-Agent. If you want to search the\n User-Agent header for the value BadBot, you base64-encode\n BadBot using MIME base64-encoding and include the resulting value,\n QmFkQm90, in the value of SearchString.
\n If you're using the CLI or one of the Amazon Web Services SDKs\n
\nThe value that you want WAF to search for. The SDK automatically base64 encodes the\n value.
", "smithy.api#required": {} } }, @@ -4739,6 +4739,18 @@ "smithy.api#documentation": "The Amazon Resource Name (ARN) of the web ACL from which you want to delete the LoggingConfiguration.
", "smithy.api#required": {} } + }, + "LogType": { + "target": "com.amazonaws.wafv2#LogType", + "traits": { + "smithy.api#documentation": "Used to distinguish between various logging options. Currently, there is one option.
\nDefault: WAF_LOGS\n
The owner of the logging configuration, which must be set to CUSTOMER for the configurations that you manage.
The log scope SECURITY_LAKE indicates a configuration that is managed through Amazon Security Lake. You can use Security Lake to collect log and event data from various sources for normalization, analysis, and management. For information, see \n Collecting data from Amazon Web Services services\n in the Amazon Security Lake user guide.
Default: CUSTOMER\n
Match against the request's JA3 fingerprint. The JA3 fingerprint is a 32-character hash derived from the TLS Client Hello of an incoming request. This fingerprint serves as a unique identifier for the client's TLS configuration. WAF calculates and logs this fingerprint for each\n\t\t\t\t\t\trequest that has enough TLS Client Hello information for the calculation. Almost \n all web requests include this information.
\nYou can use this choice only with a string match ByteMatchStatement with the PositionalConstraint set to \n EXACTLY.
You can obtain the JA3 fingerprint for client requests from the web ACL logs. \n\t\t\t\t\t\tIf WAF is able to calculate the fingerprint, it includes it in the logs. \n\t\t\t\t\t\tFor information about the logging fields, \nsee Log fields in the WAF Developer Guide.
\nProvide the JA3 fingerprint string from the logs in your string match statement\n\t\t\t\t\t\t\tspecification, to match with any future requests that have the same TLS configuration.
" + "smithy.api#documentation": "Available for use with Amazon CloudFront distributions and Application Load Balancers. Match against the request's JA3 fingerprint. The JA3 fingerprint is a 32-character hash derived from the TLS Client Hello of an incoming request. This fingerprint serves as a unique identifier for the client's TLS configuration. WAF calculates and logs this fingerprint for each\n\t\t\t\t\t\trequest that has enough TLS Client Hello information for the calculation. Almost \n all web requests include this information.
\nYou can use this choice only with a string match ByteMatchStatement with the PositionalConstraint set to \n EXACTLY.
You can obtain the JA3 fingerprint for client requests from the web ACL logs. \n\t\t\t\t\t\tIf WAF is able to calculate the fingerprint, it includes it in the logs. \n\t\t\t\t\t\tFor information about the logging fields, \nsee Log fields in the WAF Developer Guide.
\nProvide the JA3 fingerprint string from the logs in your string match statement\n\t\t\t\t\t\t\tspecification, to match with any future requests that have the same TLS configuration.
" } } }, "traits": { - "smithy.api#documentation": "Specifies a web request component to be used in a rule match statement or in a logging configuration.
\nIn a rule statement, this is the part of the web request that you want WAF to inspect. Include the single\n FieldToMatch type that you want to inspect, with additional specifications\n as needed, according to the type. You specify a single request component in\n FieldToMatch for each rule statement that requires it. To inspect more than\n one component of the web request, create a separate rule statement for each\n component.
Example JSON for a QueryString field to match:
\n \"FieldToMatch\": { \"QueryString\": {} }\n
Example JSON for a Method field to match specification:
\n \"FieldToMatch\": { \"Method\": { \"Name\": \"DELETE\" } }\n
In a logging configuration, this is used in the RedactedFields property to specify a field to \n redact from the logging records. For this use case, note the following:
Even though all FieldToMatch settings \n are available, the only valid settings for field redaction are UriPath, QueryString, SingleHeader, and Method.
In this documentation, the descriptions of the individual fields talk about specifying the web request component to inspect, \n but for field redaction, you are specifying the component type to redact from the logs.
\nSpecifies a web request component to be used in a rule match statement or in a logging configuration.
\nIn a rule statement, this is the part of the web request that you want WAF to inspect. Include the single\n FieldToMatch type that you want to inspect, with additional specifications\n as needed, according to the type. You specify a single request component in\n FieldToMatch for each rule statement that requires it. To inspect more than\n one component of the web request, create a separate rule statement for each\n component.
Example JSON for a QueryString field to match:
\n \"FieldToMatch\": { \"QueryString\": {} }\n
Example JSON for a Method field to match specification:
\n \"FieldToMatch\": { \"Method\": { \"Name\": \"DELETE\" } }\n
In a logging configuration, this is used in the RedactedFields property to specify a field to \n redact from the logging records. For this use case, note the following:
Even though all FieldToMatch settings \n are available, the only valid settings for field redaction are UriPath, QueryString, SingleHeader, and Method.
In this documentation, the descriptions of the individual fields talk about specifying the web request component to inspect, \n but for field redaction, you are specifying the component type to redact from the logs.
\nIf you have request sampling enabled, the redacted fields configuration for logging has no impact on sampling. \n The only way to exclude fields from request sampling is by disabling sampling in the web ACL visibility configuration.
\nThe Amazon Resource Name (ARN) of the web ACL for which you want to get the LoggingConfiguration.
", "smithy.api#required": {} } + }, + "LogType": { + "target": "com.amazonaws.wafv2#LogType", + "traits": { + "smithy.api#documentation": "Used to distinguish between various logging options. Currently, there is one option.
\nDefault: WAF_LOGS\n
The owner of the logging configuration, which must be set to CUSTOMER for the configurations that you manage.
The log scope SECURITY_LAKE indicates a configuration that is managed through Amazon Security Lake. You can use Security Lake to collect log and event data from various sources for normalization, analysis, and management. For information, see \n Collecting data from Amazon Web Services services\n in the Amazon Security Lake user guide.
Default: CUSTOMER\n
Match against the request's JA3 fingerprint. The JA3 fingerprint is a 32-character hash derived from the TLS Client Hello of an incoming request. This fingerprint serves as a unique identifier for the client's TLS configuration. WAF calculates and logs this fingerprint for each\n\t\t\t\t\t\trequest that has enough TLS Client Hello information for the calculation. Almost \n all web requests include this information.
\nYou can use this choice only with a string match ByteMatchStatement with the PositionalConstraint set to \n EXACTLY.
You can obtain the JA3 fingerprint for client requests from the web ACL logs. \n\t\t\t\t\t\tIf WAF is able to calculate the fingerprint, it includes it in the logs. \n\t\t\t\t\t\tFor information about the logging fields, \nsee Log fields in the WAF Developer Guide.
\nProvide the JA3 fingerprint string from the logs in your string match statement\n\t\t\t\t\t\t\tspecification, to match with any future requests that have the same TLS configuration.
" + "smithy.api#documentation": "Available for use with Amazon CloudFront distributions and Application Load Balancers. Match against the request's JA3 fingerprint. The JA3 fingerprint is a 32-character hash derived from the TLS Client Hello of an incoming request. This fingerprint serves as a unique identifier for the client's TLS configuration. WAF calculates and logs this fingerprint for each\n\t\t\t\t\t\trequest that has enough TLS Client Hello information for the calculation. Almost \n all web requests include this information.
\nYou can use this choice only with a string match ByteMatchStatement with the PositionalConstraint set to \n EXACTLY.
You can obtain the JA3 fingerprint for client requests from the web ACL logs. \n\t\t\t\t\t\tIf WAF is able to calculate the fingerprint, it includes it in the logs. \n\t\t\t\t\t\tFor information about the logging fields, \nsee Log fields in the WAF Developer Guide.
\nProvide the JA3 fingerprint string from the logs in your string match statement\n\t\t\t\t\t\t\tspecification, to match with any future requests that have the same TLS configuration.
" } }, "com.amazonaws.wafv2#JsonBody": { @@ -7688,6 +7712,12 @@ "traits": { "smithy.api#documentation": "The maximum number of objects that you want WAF to return for this request. If more \n objects are available, in the response, WAF provides a \n NextMarker value that you can use in a subsequent call to get the next batch of objects.
The owner of the logging configuration, which must be set to CUSTOMER for the configurations that you manage.
The log scope SECURITY_LAKE indicates a configuration that is managed through Amazon Security Lake. You can use Security Lake to collect log and event data from various sources for normalization, analysis, and management. For information, see \n Collecting data from Amazon Web Services services\n in the Amazon Security Lake user guide.
Default: CUSTOMER\n
The parts of the request that you want to keep out of the logs.
\nFor example, if you\n redact the SingleHeader field, the HEADER field in the logs will\n be REDACTED for all rules that use the SingleHeader\n FieldToMatch setting.
Redaction applies only to the component that's specified in the rule's FieldToMatch setting, so the SingleHeader redaction \n doesn't apply to rules that use the Headers\n FieldToMatch.
You can specify only the following fields for redaction: UriPath,\n QueryString, SingleHeader, and Method.
The parts of the request that you want to keep out of the logs.
\nFor example, if you\n redact the SingleHeader field, the HEADER field in the logs will\n be REDACTED for all rules that use the SingleHeader\n FieldToMatch setting.
Redaction applies only to the component that's specified in the rule's FieldToMatch setting, so the SingleHeader redaction \n doesn't apply to rules that use the Headers\n FieldToMatch.
You can specify only the following fields for redaction: UriPath,\n QueryString, SingleHeader, and Method.
This setting has no impact on request sampling. With request sampling, \n the only way to exclude fields is by disabling sampling in the web ACL visibility configuration.
\nFiltering that specifies which web requests are kept in the logs and which are dropped.\n You can filter on the rule action and on the web request labels that were applied by\n matching rules during web ACL evaluation.
" } + }, + "LogType": { + "target": "com.amazonaws.wafv2#LogType", + "traits": { + "smithy.api#documentation": "Used to distinguish between various logging options. Currently, there is one option.
\nDefault: WAF_LOGS\n
The owner of the logging configuration, which must be set to CUSTOMER for the configurations that you manage.
The log scope SECURITY_LAKE indicates a configuration that is managed through Amazon Security Lake. You can use Security Lake to collect log and event data from various sources for normalization, analysis, and management. For information, see \n Collecting data from Amazon Web Services services\n in the Amazon Security Lake user guide.
Default: CUSTOMER\n
Indicates whether WAF should store a sampling of the web requests that\n match the rules. You can view the sampled requests through the WAF console.
", + "smithy.api#documentation": "Indicates whether WAF should store a sampling of the web requests that\n match the rules. You can view the sampled requests through the WAF console.
\nRequest sampling doesn't provide a field redaction option, and any field redaction that you specify in your logging configuration doesn't affect sampling. \n The only way to exclude fields from request sampling is by disabling sampling in the web ACL visibility configuration.
\n