DeidentifyTemplate is the Schema for the DeidentifyTemplates API. Allows creation of templates to de-identify content.
Type
CRD
Group
datalossprevention.gcp.upbound.io
Version
v1beta1
apiVersion: datalossprevention.gcp.upbound.io/v1beta1
kind: DeidentifyTemplate
DeidentifyTemplateSpec defines the desired state of DeidentifyTemplate
No description provided.
Configuration of the deidentify template Structure is documented below.
Treat the dataset as an image and redact. Structure is documented below.
For determination of how redaction of images should occur. Structure is documented below.
Apply transformation to all findings not specified in other ImageTransformation's selectedInfoTypes.
Apply transformation to all text that doesn't match an infoType.
Apply transformation to the selected infoTypes. Structure is documented below.
Treat the dataset as free-form text and apply the same free text transformation everywhere Structure is documented below.
Transformation for each infoType. Cannot specify more than one for a given infoType. Structure is documented below.
Primitive transformation to apply to the infoType. The primitive_transformation block must only contain one argument, corresponding to the type of transformation. Structure is documented below.
Partially mask a string by replacing a given number of characters with a fixed character. Masking can start from the beginning or end of the string. Structure is documented below.
No description provided.
Pseudonymization method that generates deterministic encryption for the given input. Outputs a base64 encoded representation of the encrypted output. Uses AES-SIV based on the RFC https://tools.ietf.org/html/rfc5297. Structure is documented below.
Points to the field that contains the context, for example, an entity id. If set, must also set cryptoKey. If set, shift will be consistent for the given context. Structure is documented below.
Causes the shift to be computed based on this key and the context. This results in the same shift for the same context and cryptoKey. If set, must also set context. Can only be applied to table items. Structure is documented below.
KMS wrapped key. Include to use an existing data crypto key wrapped by KMS. The wrapped key must be a 128-, 192-, or 256-bit key. Authorization requires the following IAM permissions when sending a request to perform a crypto transformation using a KMS-wrapped crypto key: dlp.kms.encrypt For more information, see Creating a wrapped key. Note: When you use Cloud KMS for cryptographic operations, charges apply. Structure is documented below.
The custom infoType to annotate the surrogate with. This annotation will be applied to the surrogate by prefixing it with the name of the custom infoType followed by the number of characters comprising the surrogate. The following scheme defines the format: info_type_name(surrogate_character_count):surrogate For example, if the name of custom infoType is 'MY_TOKEN_INFO_TYPE' and the surrogate is 'abc', the full replacement value will be: 'MY_TOKEN_INFO_TYPE(3):abc' This annotation identifies the surrogate when inspecting content using the custom infoType SurrogateType. This facilitates reversal of the surrogate when it occurs in free text. In order for inspection to work properly, the name of this infoType must not occur naturally anywhere in your data; otherwise, inspection may find a surrogate that does not correspond to an actual identifier. Therefore, choose your custom infoType name carefully after considering what your data looks like. One way to select a name that has a high chance of yielding reliable detection is to include one or more unicode characters that are highly improbable to exist in your data. For example, assuming your data is entered from a regular ASCII keyboard, the symbol with the hex code point 29DD might be used like so: ⧝MY_TOKEN_TYPE Structure is documented below.
Replaces an identifier with a surrogate using Format Preserving Encryption (FPE) with the FFX mode of operation; however when used in the content.reidentify API method, it serves the opposite function by reversing the surrogate back into the original identifier. The identifier must be encoded as ASCII. For a given crypto key and context, the same identifier will be replaced with the same surrogate. Identifiers must be at least two characters long. In the case that the identifier is the empty string, it will be skipped. See https://cloud.google.com/dlp/docs/pseudonymization to learn more. Note: We recommend using CryptoDeterministicConfig for all use cases which do not require preserving the input alphabet space and size, plus warrant referential integrity. Structure is documented below.
Points to the field that contains the context, for example, an entity id. If set, must also set cryptoKey. If set, shift will be consistent for the given context. Structure is documented below.
Causes the shift to be computed based on this key and the context. This results in the same shift for the same context and cryptoKey. If set, must also set context. Can only be applied to table items. Structure is documented below.
KMS wrapped key. Include to use an existing data crypto key wrapped by KMS. The wrapped key must be a 128-, 192-, or 256-bit key. Authorization requires the following IAM permissions when sending a request to perform a crypto transformation using a KMS-wrapped crypto key: dlp.kms.encrypt For more information, see Creating a wrapped key. Note: When you use Cloud KMS for cryptographic operations, charges apply. Structure is documented below.
The custom infoType to annotate the surrogate with. This annotation will be applied to the surrogate by prefixing it with the name of the custom infoType followed by the number of characters comprising the surrogate. The following scheme defines the format: info_type_name(surrogate_character_count):surrogate For example, if the name of custom infoType is 'MY_TOKEN_INFO_TYPE' and the surrogate is 'abc', the full replacement value will be: 'MY_TOKEN_INFO_TYPE(3):abc' This annotation identifies the surrogate when inspecting content using the custom infoType SurrogateType. This facilitates reversal of the surrogate when it occurs in free text. In order for inspection to work properly, the name of this infoType must not occur naturally anywhere in your data; otherwise, inspection may find a surrogate that does not correspond to an actual identifier. Therefore, choose your custom infoType name carefully after considering what your data looks like. One way to select a name that has a high chance of yielding reliable detection is to include one or more unicode characters that are highly improbable to exist in your data. For example, assuming your data is entered from a regular ASCII keyboard, the symbol with the hex code point 29DD might be used like so: ⧝MY_TOKEN_TYPE Structure is documented below.
Replace each input value with a given value. Structure is documented below.
Replace each input value with a given value. The new_value block must only contain one argument. For example when replacing the contents of a string-type field, only string_value should be set. Structure is documented below.
Replace with a value randomly drawn (with replacement) from a dictionary. Structure is documented below.
A list of words to select from for random replacement. The limits page contains details about the size limits of dictionaries. Structure is documented below.
Words or phrases defining the dictionary. The dictionary must contain at least one phrase and every phrase must contain at least 2 characters that are letters or digits.
Treat the dataset as structured. Transformations can be applied to specific locations within structured datasets, such as transforming a column within a table. Structure is documented below.
Transform the record by applying various field transformations. Structure is documented below.
A condition that when it evaluates to true will result in the record being evaluated to be suppressed from the transformed content. Structure is documented below.
An expression, consisting of an operator and conditions. Structure is documented below.
Conditions to apply to the expression. Structure is documented below.
Conditions to apply to the expression. Structure is documented below.
Field within the record this condition is evaluated against. Structure is documented below.
Value to compare against. The value block must only contain one argument. For example when a condition is evaluated against a string-type field, only string_value should be set. This argument is mandatory, except for conditions using the EXISTS operator. Structure is documented below.
Input field(s) to apply the transformation to. When you have columns that reference their position within a list, omit the index from the FieldId. FieldId name matching ignores the index. For example, instead of "contact.nums[0].type", use "contact.nums.type". Structure is documented below.
Primitive transformation to apply to the infoType. The primitive_transformation block must only contain one argument, corresponding to the type of transformation. Structure is documented below.
Generalization function that buckets values based on ranges. The ranges and replacement values are dynamically provided by the user for custom behavior, such as 1-30 -> LOW 31-65 -> MEDIUM 66-100 -> HIGH This can be used on data of type: number, long, string, timestamp. If the provided value type differs from the type of data being transformed, we will first attempt converting the type of the data to be transformed to match the type of the bound before comparing. See https://cloud.google.com/dlp/docs/concepts-bucketing to learn more. Structure is documented below.
Set of buckets. Ranges must be non-overlapping. Bucket is represented as a range, along with replacement values. Structure is documented below.
Upper bound of the range, exclusive; type must match min. The max block must only contain one argument. See the bucketing_config block description for more information about choosing a data type. Structure is documented below.
Lower bound of the range, inclusive. Type should be the same as max if used. The min block must only contain one argument. See the bucketing_config block description for more information about choosing a data type. Structure is documented below.
Replacement value for this bucket. The replacement_value block must only contain one argument. Structure is documented below.
Partially mask a string by replacing a given number of characters with a fixed character. Masking can start from the beginning or end of the string. Structure is documented below.
No description provided.
Pseudonymization method that generates deterministic encryption for the given input. Outputs a base64 encoded representation of the encrypted output. Uses AES-SIV based on the RFC https://tools.ietf.org/html/rfc5297. Structure is documented below.
Points to the field that contains the context, for example, an entity id. If set, must also set cryptoKey. If set, shift will be consistent for the given context. Structure is documented below.
Causes the shift to be computed based on this key and the context. This results in the same shift for the same context and cryptoKey. If set, must also set context. Can only be applied to table items. Structure is documented below.
KMS wrapped key. Include to use an existing data crypto key wrapped by KMS. The wrapped key must be a 128-, 192-, or 256-bit key. Authorization requires the following IAM permissions when sending a request to perform a crypto transformation using a KMS-wrapped crypto key: dlp.kms.encrypt For more information, see Creating a wrapped key. Note: When you use Cloud KMS for cryptographic operations, charges apply. Structure is documented below.
The custom infoType to annotate the surrogate with. This annotation will be applied to the surrogate by prefixing it with the name of the custom infoType followed by the number of characters comprising the surrogate. The following scheme defines the format: info_type_name(surrogate_character_count):surrogate For example, if the name of custom infoType is 'MY_TOKEN_INFO_TYPE' and the surrogate is 'abc', the full replacement value will be: 'MY_TOKEN_INFO_TYPE(3):abc' This annotation identifies the surrogate when inspecting content using the custom infoType SurrogateType. This facilitates reversal of the surrogate when it occurs in free text. In order for inspection to work properly, the name of this infoType must not occur naturally anywhere in your data; otherwise, inspection may find a surrogate that does not correspond to an actual identifier. Therefore, choose your custom infoType name carefully after considering what your data looks like. One way to select a name that has a high chance of yielding reliable detection is to include one or more unicode characters that are highly improbable to exist in your data. For example, assuming your data is entered from a regular ASCII keyboard, the symbol with the hex code point 29DD might be used like so: ⧝MY_TOKEN_TYPE Structure is documented below.
Pseudonymization method that generates surrogates via cryptographic hashing. Uses SHA-256. The key size must be either 32 or 64 bytes. Outputs a base64 encoded representation of the hashed output (for example, L7k0BHmF1ha5U3NfGykjro4xWi1MPVQPjhMAZbSV9mM=). Currently, only string and integer values can be hashed. See https://cloud.google.com/dlp/docs/pseudonymization to learn more. Structure is documented below.
Causes the shift to be computed based on this key and the context. This results in the same shift for the same context and cryptoKey. If set, must also set context. Can only be applied to table items. Structure is documented below.
KMS wrapped key. Include to use an existing data crypto key wrapped by KMS. The wrapped key must be a 128-, 192-, or 256-bit key. Authorization requires the following IAM permissions when sending a request to perform a crypto transformation using a KMS-wrapped crypto key: dlp.kms.encrypt For more information, see Creating a wrapped key. Note: When you use Cloud KMS for cryptographic operations, charges apply. Structure is documented below.
Replaces an identifier with a surrogate using Format Preserving Encryption (FPE) with the FFX mode of operation; however when used in the content.reidentify API method, it serves the opposite function by reversing the surrogate back into the original identifier. The identifier must be encoded as ASCII. For a given crypto key and context, the same identifier will be replaced with the same surrogate. Identifiers must be at least two characters long. In the case that the identifier is the empty string, it will be skipped. See https://cloud.google.com/dlp/docs/pseudonymization to learn more. Note: We recommend using CryptoDeterministicConfig for all use cases which do not require preserving the input alphabet space and size, plus warrant referential integrity. Structure is documented below.
Points to the field that contains the context, for example, an entity id. If set, must also set cryptoKey. If set, shift will be consistent for the given context. Structure is documented below.
Causes the shift to be computed based on this key and the context. This results in the same shift for the same context and cryptoKey. If set, must also set context. Can only be applied to table items. Structure is documented below.
KMS wrapped key. Include to use an existing data crypto key wrapped by KMS. The wrapped key must be a 128-, 192-, or 256-bit key. Authorization requires the following IAM permissions when sending a request to perform a crypto transformation using a KMS-wrapped crypto key: dlp.kms.encrypt For more information, see Creating a wrapped key. Note: When you use Cloud KMS for cryptographic operations, charges apply. Structure is documented below.
The custom infoType to annotate the surrogate with. This annotation will be applied to the surrogate by prefixing it with the name of the custom infoType followed by the number of characters comprising the surrogate. The following scheme defines the format: info_type_name(surrogate_character_count):surrogate For example, if the name of custom infoType is 'MY_TOKEN_INFO_TYPE' and the surrogate is 'abc', the full replacement value will be: 'MY_TOKEN_INFO_TYPE(3):abc' This annotation identifies the surrogate when inspecting content using the custom infoType SurrogateType. This facilitates reversal of the surrogate when it occurs in free text. In order for inspection to work properly, the name of this infoType must not occur naturally anywhere in your data; otherwise, inspection may find a surrogate that does not correspond to an actual identifier. Therefore, choose your custom infoType name carefully after considering what your data looks like. One way to select a name that has a high chance of yielding reliable detection is to include one or more unicode characters that are highly improbable to exist in your data. For example, assuming your data is entered from a regular ASCII keyboard, the symbol with the hex code point 29DD might be used like so: ⧝MY_TOKEN_TYPE Structure is documented below.
Shifts dates by random number of days, with option to be consistent for the same context. See https://cloud.google.com/dlp/docs/concepts-date-shifting to learn more. Structure is documented below.
Points to the field that contains the context, for example, an entity id. If set, must also set cryptoKey. If set, shift will be consistent for the given context. Structure is documented below.
Causes the shift to be computed based on this key and the context. This results in the same shift for the same context and cryptoKey. If set, must also set context. Can only be applied to table items. Structure is documented below.
KMS wrapped key. Include to use an existing data crypto key wrapped by KMS. The wrapped key must be a 128-, 192-, or 256-bit key. Authorization requires the following IAM permissions when sending a request to perform a crypto transformation using a KMS-wrapped crypto key: dlp.kms.encrypt For more information, see Creating a wrapped key. Note: When you use Cloud KMS for cryptographic operations, charges apply. Structure is documented below.
Buckets values based on fixed size ranges. The Bucketing transformation can provide all of this functionality, but requires more configuration. This message is provided as a convenience to the user for simple bucketing strategies. The transformed value will be a hyphenated string of {lower_bound}-{upper_bound}. For example, if lower_bound = 10 and upper_bound = 20, all values that are within this bucket will be replaced with "10-20". This can be used on data of type: double, long. If the bound Value type differs from the type of data being transformed, we will first attempt converting the type of the data to be transformed to match the type of the bound before comparing. See https://cloud.google.com/dlp/docs/concepts-bucketing to learn more. Structure is documented below.
Lower bound value of buckets. All values less than lower_bound are grouped together into a single bucket; for example if lower_bound = 10, then all values less than 10 are replaced with the value "-10". The lower_bound block must only contain one argument. See the fixed_size_bucketing_config block description for more information about choosing a data type. Structure is documented below.
Upper bound value of buckets. All values greater than upper_bound are grouped together into a single bucket; for example if upper_bound = 89, then all values greater than 89 are replaced with the value "89+". The upper_bound block must only contain one argument. See the fixed_size_bucketing_config block description for more information about choosing a data type. Structure is documented below.
Redact a given value. For example, if used with an InfoTypeTransformation transforming PHONE_NUMBER, and input 'My phone number is 206-555-0123', the output would be 'My phone number is '.
Replace each input value with a given value. Structure is documented below.
Replace each input value with a given value. The new_value block must only contain one argument. For example when replacing the contents of a string-type field, only string_value should be set. Structure is documented below.
Replace with a value randomly drawn (with replacement) from a dictionary. Structure is documented below.
A list of words to select from for random replacement. The limits page contains details about the size limits of dictionaries. Structure is documented below.
Words or phrases defining the dictionary. The dictionary must contain at least one phrase and every phrase must contain at least 2 characters that are letters or digits.
For use with Date, Timestamp, and TimeOfDay, extract or preserve a portion of the value. Structure is documented below.
Configuration defining which records get suppressed entirely. Records that match any suppression rule are omitted from the output. Structure is documented below.
A condition that when it evaluates to true will result in the record being evaluated to be suppressed from the transformed content. Structure is documented below.
An expression, consisting of an operator and conditions. Structure is documented below.
Conditions to apply to the expression. Structure is documented below.
Conditions to apply to the expression. Structure is documented below.
Field within the record this condition is evaluated against. Structure is documented below.
Value to compare against. The value block must only contain one argument. For example when a condition is evaluated against a string-type field, only string_value should be set. This argument is mandatory, except for conditions using the EXISTS operator. Structure is documented below.
ProviderConfigReference specifies how the provider that will be used to create, observe, update, and delete this managed resource should be configured.
Policies for referencing.
ProviderReference specifies the provider that will be used to create, observe, update, and delete this managed resource. Deprecated: Please use ProviderConfigReference, i.e. providerConfigRef
Policies for referencing.
PublishConnectionDetailsTo specifies the connection secret config which contains a name, metadata and a reference to secret store config to which any connection details for this managed resource should be written. Connection details frequently include the endpoint, username, and password required to connect to the managed resource.
WriteConnectionSecretToReference specifies the namespace and name of a Secret to which any connection details for this managed resource should be written. Connection details frequently include the endpoint, username, and password required to connect to the managed resource. This field is planned to be replaced in a future release in favor of PublishConnectionDetailsTo. Currently, both could be set independently and connection details would be published to both without affecting each other.
DeidentifyTemplateStatus defines the observed state of DeidentifyTemplate.
No description provided.
Configuration of the deidentify template Structure is documented below.
Treat the dataset as an image and redact. Structure is documented below.
For determination of how redaction of images should occur. Structure is documented below.
Apply transformation to all findings not specified in other ImageTransformation's selectedInfoTypes.
Apply transformation to all text that doesn't match an infoType.
Apply transformation to the selected infoTypes. Structure is documented below.
Treat the dataset as free-form text and apply the same free text transformation everywhere Structure is documented below.
Transformation for each infoType. Cannot specify more than one for a given infoType. Structure is documented below.
Primitive transformation to apply to the infoType. The primitive_transformation block must only contain one argument, corresponding to the type of transformation. Structure is documented below.
Partially mask a string by replacing a given number of characters with a fixed character. Masking can start from the beginning or end of the string. Structure is documented below.
No description provided.
Pseudonymization method that generates deterministic encryption for the given input. Outputs a base64 encoded representation of the encrypted output. Uses AES-SIV based on the RFC https://tools.ietf.org/html/rfc5297. Structure is documented below.
Points to the field that contains the context, for example, an entity id. If set, must also set cryptoKey. If set, shift will be consistent for the given context. Structure is documented below.
Causes the shift to be computed based on this key and the context. This results in the same shift for the same context and cryptoKey. If set, must also set context. Can only be applied to table items. Structure is documented below.
KMS wrapped key. Include to use an existing data crypto key wrapped by KMS. The wrapped key must be a 128-, 192-, or 256-bit key. Authorization requires the following IAM permissions when sending a request to perform a crypto transformation using a KMS-wrapped crypto key: dlp.kms.encrypt For more information, see Creating a wrapped key. Note: When you use Cloud KMS for cryptographic operations, charges apply. Structure is documented below.
The custom infoType to annotate the surrogate with. This annotation will be applied to the surrogate by prefixing it with the name of the custom infoType followed by the number of characters comprising the surrogate. The following scheme defines the format: info_type_name(surrogate_character_count):surrogate For example, if the name of custom infoType is 'MY_TOKEN_INFO_TYPE' and the surrogate is 'abc', the full replacement value will be: 'MY_TOKEN_INFO_TYPE(3):abc' This annotation identifies the surrogate when inspecting content using the custom infoType SurrogateType. This facilitates reversal of the surrogate when it occurs in free text. In order for inspection to work properly, the name of this infoType must not occur naturally anywhere in your data; otherwise, inspection may find a surrogate that does not correspond to an actual identifier. Therefore, choose your custom infoType name carefully after considering what your data looks like. One way to select a name that has a high chance of yielding reliable detection is to include one or more unicode characters that are highly improbable to exist in your data. For example, assuming your data is entered from a regular ASCII keyboard, the symbol with the hex code point 29DD might be used like so: ⧝MY_TOKEN_TYPE Structure is documented below.
Replaces an identifier with a surrogate using Format Preserving Encryption (FPE) with the FFX mode of operation; however when used in the content.reidentify API method, it serves the opposite function by reversing the surrogate back into the original identifier. The identifier must be encoded as ASCII. For a given crypto key and context, the same identifier will be replaced with the same surrogate. Identifiers must be at least two characters long. In the case that the identifier is the empty string, it will be skipped. See https://cloud.google.com/dlp/docs/pseudonymization to learn more. Note: We recommend using CryptoDeterministicConfig for all use cases which do not require preserving the input alphabet space and size, plus warrant referential integrity. Structure is documented below.
Points to the field that contains the context, for example, an entity id. If set, must also set cryptoKey. If set, shift will be consistent for the given context. Structure is documented below.
Causes the shift to be computed based on this key and the context. This results in the same shift for the same context and cryptoKey. If set, must also set context. Can only be applied to table items. Structure is documented below.
KMS wrapped key. Include to use an existing data crypto key wrapped by KMS. The wrapped key must be a 128-, 192-, or 256-bit key. Authorization requires the following IAM permissions when sending a request to perform a crypto transformation using a KMS-wrapped crypto key: dlp.kms.encrypt For more information, see Creating a wrapped key. Note: When you use Cloud KMS for cryptographic operations, charges apply. Structure is documented below.
The custom infoType to annotate the surrogate with. This annotation will be applied to the surrogate by prefixing it with the name of the custom infoType followed by the number of characters comprising the surrogate. The following scheme defines the format: info_type_name(surrogate_character_count):surrogate For example, if the name of custom infoType is 'MY_TOKEN_INFO_TYPE' and the surrogate is 'abc', the full replacement value will be: 'MY_TOKEN_INFO_TYPE(3):abc' This annotation identifies the surrogate when inspecting content using the custom infoType SurrogateType. This facilitates reversal of the surrogate when it occurs in free text. In order for inspection to work properly, the name of this infoType must not occur naturally anywhere in your data; otherwise, inspection may find a surrogate that does not correspond to an actual identifier. Therefore, choose your custom infoType name carefully after considering what your data looks like. One way to select a name that has a high chance of yielding reliable detection is to include one or more unicode characters that are highly improbable to exist in your data. For example, assuming your data is entered from a regular ASCII keyboard, the symbol with the hex code point 29DD might be used like so: ⧝MY_TOKEN_TYPE Structure is documented below.
Replace each input value with a given value. Structure is documented below.
Replace each input value with a given value. The new_value block must only contain one argument. For example when replacing the contents of a string-type field, only string_value should be set. Structure is documented below.
Replace with a value randomly drawn (with replacement) from a dictionary. Structure is documented below.
A list of words to select from for random replacement. The limits page contains details about the size limits of dictionaries. Structure is documented below.
Words or phrases defining the dictionary. The dictionary must contain at least one phrase and every phrase must contain at least 2 characters that are letters or digits.
Treat the dataset as structured. Transformations can be applied to specific locations within structured datasets, such as transforming a column within a table. Structure is documented below.
Transform the record by applying various field transformations. Structure is documented below.
A condition that when it evaluates to true will result in the record being evaluated to be suppressed from the transformed content. Structure is documented below.
An expression, consisting of an operator and conditions. Structure is documented below.
Conditions to apply to the expression. Structure is documented below.
Conditions to apply to the expression. Structure is documented below.
Field within the record this condition is evaluated against. Structure is documented below.
Value to compare against. The value block must only contain one argument. For example when a condition is evaluated against a string-type field, only string_value should be set. This argument is mandatory, except for conditions using the EXISTS operator. Structure is documented below.
Input field(s) to apply the transformation to. When you have columns that reference their position within a list, omit the index from the FieldId. FieldId name matching ignores the index. For example, instead of "contact.nums[0].type", use "contact.nums.type". Structure is documented below.
Primitive transformation to apply to the infoType. The primitive_transformation block must only contain one argument, corresponding to the type of transformation. Structure is documented below.
Generalization function that buckets values based on ranges. The ranges and replacement values are dynamically provided by the user for custom behavior, such as 1-30 -> LOW 31-65 -> MEDIUM 66-100 -> HIGH This can be used on data of type: number, long, string, timestamp. If the provided value type differs from the type of data being transformed, we will first attempt converting the type of the data to be transformed to match the type of the bound before comparing. See https://cloud.google.com/dlp/docs/concepts-bucketing to learn more. Structure is documented below.
Set of buckets. Ranges must be non-overlapping. Bucket is represented as a range, along with replacement values. Structure is documented below.
Upper bound of the range, exclusive; type must match min. The max block must only contain one argument. See the bucketing_config block description for more information about choosing a data type. Structure is documented below.
Lower bound of the range, inclusive. Type should be the same as max if used. The min block must only contain one argument. See the bucketing_config block description for more information about choosing a data type. Structure is documented below.
Replacement value for this bucket. The replacement_value block must only contain one argument. Structure is documented below.
Partially mask a string by replacing a given number of characters with a fixed character. Masking can start from the beginning or end of the string. Structure is documented below.
No description provided.
Pseudonymization method that generates deterministic encryption for the given input. Outputs a base64 encoded representation of the encrypted output. Uses AES-SIV based on the RFC https://tools.ietf.org/html/rfc5297. Structure is documented below.
Points to the field that contains the context, for example, an entity id. If set, must also set cryptoKey. If set, shift will be consistent for the given context. Structure is documented below.
Causes the shift to be computed based on this key and the context. This results in the same shift for the same context and cryptoKey. If set, must also set context. Can only be applied to table items. Structure is documented below.
KMS wrapped key. Include to use an existing data crypto key wrapped by KMS. The wrapped key must be a 128-, 192-, or 256-bit key. Authorization requires the following IAM permissions when sending a request to perform a crypto transformation using a KMS-wrapped crypto key: dlp.kms.encrypt For more information, see Creating a wrapped key. Note: When you use Cloud KMS for cryptographic operations, charges apply. Structure is documented below.
The custom infoType to annotate the surrogate with. This annotation will be applied to the surrogate by prefixing it with the name of the custom infoType followed by the number of characters comprising the surrogate. The following scheme defines the format: info_type_name(surrogate_character_count):surrogate For example, if the name of custom infoType is 'MY_TOKEN_INFO_TYPE' and the surrogate is 'abc', the full replacement value will be: 'MY_TOKEN_INFO_TYPE(3):abc' This annotation identifies the surrogate when inspecting content using the custom infoType SurrogateType. This facilitates reversal of the surrogate when it occurs in free text. In order for inspection to work properly, the name of this infoType must not occur naturally anywhere in your data; otherwise, inspection may find a surrogate that does not correspond to an actual identifier. Therefore, choose your custom infoType name carefully after considering what your data looks like. One way to select a name that has a high chance of yielding reliable detection is to include one or more unicode characters that are highly improbable to exist in your data. For example, assuming your data is entered from a regular ASCII keyboard, the symbol with the hex code point 29DD might be used like so: ⧝MY_TOKEN_TYPE Structure is documented below.
Pseudonymization method that generates surrogates via cryptographic hashing. Uses SHA-256. The key size must be either 32 or 64 bytes. Outputs a base64 encoded representation of the hashed output (for example, L7k0BHmF1ha5U3NfGykjro4xWi1MPVQPjhMAZbSV9mM=). Currently, only string and integer values can be hashed. See https://cloud.google.com/dlp/docs/pseudonymization to learn more. Structure is documented below.
Causes the shift to be computed based on this key and the context. This results in the same shift for the same context and cryptoKey. If set, must also set context. Can only be applied to table items. Structure is documented below.
KMS wrapped key. Include to use an existing data crypto key wrapped by KMS. The wrapped key must be a 128-, 192-, or 256-bit key. Authorization requires the following IAM permissions when sending a request to perform a crypto transformation using a KMS-wrapped crypto key: dlp.kms.encrypt For more information, see Creating a wrapped key. Note: When you use Cloud KMS for cryptographic operations, charges apply. Structure is documented below.
Replaces an identifier with a surrogate using Format Preserving Encryption (FPE) with the FFX mode of operation; however when used in the content.reidentify API method, it serves the opposite function by reversing the surrogate back into the original identifier. The identifier must be encoded as ASCII. For a given crypto key and context, the same identifier will be replaced with the same surrogate. Identifiers must be at least two characters long. In the case that the identifier is the empty string, it will be skipped. See https://cloud.google.com/dlp/docs/pseudonymization to learn more. Note: We recommend using CryptoDeterministicConfig for all use cases which do not require preserving the input alphabet space and size, plus warrant referential integrity. Structure is documented below.
Points to the field that contains the context, for example, an entity id. If set, must also set cryptoKey. If set, shift will be consistent for the given context. Structure is documented below.
Causes the shift to be computed based on this key and the context. This results in the same shift for the same context and cryptoKey. If set, must also set context. Can only be applied to table items. Structure is documented below.
KMS wrapped key. Include to use an existing data crypto key wrapped by KMS. The wrapped key must be a 128-, 192-, or 256-bit key. Authorization requires the following IAM permissions when sending a request to perform a crypto transformation using a KMS-wrapped crypto key: dlp.kms.encrypt For more information, see Creating a wrapped key. Note: When you use Cloud KMS for cryptographic operations, charges apply. Structure is documented below.
The custom infoType to annotate the surrogate with. This annotation will be applied to the surrogate by prefixing it with the name of the custom infoType followed by the number of characters comprising the surrogate. The following scheme defines the format: info_type_name(surrogate_character_count):surrogate For example, if the name of custom infoType is 'MY_TOKEN_INFO_TYPE' and the surrogate is 'abc', the full replacement value will be: 'MY_TOKEN_INFO_TYPE(3):abc' This annotation identifies the surrogate when inspecting content using the custom infoType SurrogateType. This facilitates reversal of the surrogate when it occurs in free text. In order for inspection to work properly, the name of this infoType must not occur naturally anywhere in your data; otherwise, inspection may find a surrogate that does not correspond to an actual identifier. Therefore, choose your custom infoType name carefully after considering what your data looks like. One way to select a name that has a high chance of yielding reliable detection is to include one or more unicode characters that are highly improbable to exist in your data. For example, assuming your data is entered from a regular ASCII keyboard, the symbol with the hex code point 29DD might be used like so: ⧝MY_TOKEN_TYPE Structure is documented below.
Shifts dates by random number of days, with option to be consistent for the same context. See https://cloud.google.com/dlp/docs/concepts-date-shifting to learn more. Structure is documented below.
Points to the field that contains the context, for example, an entity id. If set, must also set cryptoKey. If set, shift will be consistent for the given context. Structure is documented below.
Causes the shift to be computed based on this key and the context. This results in the same shift for the same context and cryptoKey. If set, must also set context. Can only be applied to table items. Structure is documented below.
KMS wrapped key. Include to use an existing data crypto key wrapped by KMS. The wrapped key must be a 128-, 192-, or 256-bit key. Authorization requires the following IAM permissions when sending a request to perform a crypto transformation using a KMS-wrapped crypto key: dlp.kms.encrypt For more information, see Creating a wrapped key. Note: When you use Cloud KMS for cryptographic operations, charges apply. Structure is documented below.
Buckets values based on fixed size ranges. The Bucketing transformation can provide all of this functionality, but requires more configuration. This message is provided as a convenience to the user for simple bucketing strategies. The transformed value will be a hyphenated string of {lower_bound}-{upper_bound}. For example, if lower_bound = 10 and upper_bound = 20, all values that are within this bucket will be replaced with "10-20". This can be used on data of type: double, long. If the bound Value type differs from the type of data being transformed, we will first attempt converting the type of the data to be transformed to match the type of the bound before comparing. See https://cloud.google.com/dlp/docs/concepts-bucketing to learn more. Structure is documented below.
Lower bound value of buckets. All values less than lower_bound are grouped together into a single bucket; for example if lower_bound = 10, then all values less than 10 are replaced with the value "-10". The lower_bound block must only contain one argument. See the fixed_size_bucketing_config block description for more information about choosing a data type. Structure is documented below.
Upper bound value of buckets. All values greater than upper_bound are grouped together into a single bucket; for example if upper_bound = 89, then all values greater than 89 are replaced with the value "89+". The upper_bound block must only contain one argument. See the fixed_size_bucketing_config block description for more information about choosing a data type. Structure is documented below.
Redact a given value. For example, if used with an InfoTypeTransformation transforming PHONE_NUMBER, and input 'My phone number is 206-555-0123', the output would be 'My phone number is '.
Replace each input value with a given value. Structure is documented below.
Replace each input value with a given value. The new_value block must only contain one argument. For example when replacing the contents of a string-type field, only string_value should be set. Structure is documented below.
Replace with a value randomly drawn (with replacement) from a dictionary. Structure is documented below.
A list of words to select from for random replacement. The limits page contains details about the size limits of dictionaries. Structure is documented below.
Words or phrases defining the dictionary. The dictionary must contain at least one phrase and every phrase must contain at least 2 characters that are letters or digits.
For use with Date, Timestamp, and TimeOfDay, extract or preserve a portion of the value. Structure is documented below.
Configuration defining which records get suppressed entirely. Records that match any suppression rule are omitted from the output. Structure is documented below.
A condition that when it evaluates to true will result in the record being evaluated to be suppressed from the transformed content. Structure is documented below.
An expression, consisting of an operator and conditions. Structure is documented below.
Conditions to apply to the expression. Structure is documented below.
Conditions to apply to the expression. Structure is documented below.
Field within the record this condition is evaluated against. Structure is documented below.
Value to compare against. The value block must only contain one argument. For example when a condition is evaluated against a string-type field, only string_value should be set. This argument is mandatory, except for conditions using the EXISTS operator. Structure is documented below.
Conditions of the resource.
basic
apiVersion: datalossprevention.gcp.upbound.io/v1beta1
kind: DeidentifyTemplate
metadata:
annotations:
meta.upbound.io/example-id: datalossprevention/v1beta1/deidentifytemplate
upjet.upbound.io/manual-intervention: The resource requires a real Project ID
labels:
testing.upbound.io/example-name: basic
name: basic
spec:
forProvider:
deidentifyConfig:
- infoTypeTransformations:
- transformations:
- infoTypes:
- name: FIRST_NAME
primitiveTransformation:
- replaceWithInfoTypeConfig: true
- infoTypes:
- name: PHONE_NUMBER
- name: AGE
primitiveTransformation:
- replaceConfig:
- newValue:
- integerValue: 9
- infoTypes:
- name: EMAIL_ADDRESS
- name: LAST_NAME
primitiveTransformation:
- characterMaskConfig:
- charactersToIgnore:
- commonCharactersToIgnore: PUNCTUATION
maskingCharacter: X
numberToMask: 4
reverseOrder: true
- infoTypes:
- name: DATE_OF_BIRTH
primitiveTransformation:
- replaceConfig:
- newValue:
- dateValue:
- day: 1
month: 1
year: 2020
- infoTypes:
- name: CREDIT_CARD_NUMBER
primitiveTransformation:
- cryptoDeterministicConfig:
- context:
- name: sometweak
cryptoKey:
- transient:
- name: beep
surrogateInfoType:
- name: abc
description: Description
displayName: Displayname
parent: projects/&{project_id}
© 2022 Upbound, Inc.
Discover the building blocksfor your internal cloud platform.