terraform

Commit Graph

Author	SHA1	Message	Date
Alisdair McDiarmid	5e30d58dc2	command/jsonplan: Add output change sensitivity When an output value changes, we have a small amount of information we can convey about its sensitivity. If either the output was previously marked sensitive, or is currently marked sensitive in the config, this is tracked in the output change data. This commit encodes this boolean in the change struct's `before_sensitive` and `after_sensitive` fields, in the a way which matches resource value sensitivity. Since we have so little information to work with, these two values will always be booleans, and always equal each. This is logically consistent with how else we want to obscure sensitive data: a changing output which was or is marked sensitive should not have the value shown in human-readable output.	5 years ago
Alisdair McDiarmid	e27aacebf9	command/jsonplan: Add sensitive value mapping data Similar to `after_unknown`, `before_sensitive` and `after_sensitive` are values with similar structure to `before` and `after` which encode the presence of sensitive values in a planned change. These should be used to obscure sensitive values from human-readable output. These values follow the same structure as the `before` and `after` values, replacing sensitive values with `true`, and non-sensitive values with `false`. Following the `after_unknown` precedent, we omit non-sensitive `false` values for object attributes/map values, to make serialization more compact. One difference from `after_unknown` is that a sensitive complex value (collection or structural type) is replaced with `true`. If the complex value itself is sensitive, all of its contents should be obscured.	5 years ago
Alisdair McDiarmid	7cae76383a	cli: Fix for provider requirements in JSON plan The JSON plan output format includes a serialized, simplified version of the configuration. One component of this config is a map of provider configurations, which includes version constraints. Until now, only version constraints specified in the provider config blocks were exposed in the JSON plan output. This is a deprecated method of specifying provider versions, and the recommended use of a required_providers block resulted in the version constraints being omitted. This commit fixes this with two changes: - When processing the provider configurations from a module, output the fully-merged version constraints for the entire module, instead of any constraints set in the provider configuration block itself; - After all provider configurations are processed, iterate over the required_providers entries to ensure that any configuration-less providers are output to the JSON plan too. No changes are necessary to the structure of the JSON plan output, so this is effectively a semantic level bug fix.	5 years ago

Author

SHA1

Message

Date

Alisdair McDiarmid

5e30d58dc2

command/jsonplan: Add output change sensitivity

When an output value changes, we have a small amount of information we
can convey about its sensitivity. If either the output was previously
marked sensitive, or is currently marked sensitive in the config, this
is tracked in the output change data.

This commit encodes this boolean in the change struct's
`before_sensitive` and `after_sensitive` fields, in the a way which
matches resource value sensitivity. Since we have so little information
to work with, these two values will always be booleans, and always equal
each.

This is logically consistent with how else we want to obscure sensitive
data: a changing output which was or is marked sensitive should not have
the value shown in human-readable output.

Alisdair McDiarmid

e27aacebf9

command/jsonplan: Add sensitive value mapping data

Similar to `after_unknown`, `before_sensitive` and `after_sensitive` are
values with similar structure to `before` and `after` which encode the
presence of sensitive values in a planned change. These should be used
to obscure sensitive values from human-readable output.

These values follow the same structure as the `before` and `after`
values, replacing sensitive values with `true`, and non-sensitive values
with `false`. Following the `after_unknown` precedent, we omit
non-sensitive `false` values for object attributes/map values, to make
serialization more compact.

One difference from `after_unknown` is that a sensitive complex value
(collection or structural type) is replaced with `true`. If the complex
value itself is sensitive, all of its contents should be obscured.

Alisdair McDiarmid

7cae76383a

cli: Fix for provider requirements in JSON plan

The JSON plan output format includes a serialized, simplified version of
the configuration. One component of this config is a map of provider
configurations, which includes version constraints.

Until now, only version constraints specified in the provider config
blocks were exposed in the JSON plan output. This is a deprecated method
of specifying provider versions, and the recommended use of a
required_providers block resulted in the version constraints being
omitted.

This commit fixes this with two changes:

- When processing the provider configurations from a module, output the
  fully-merged version constraints for the entire module, instead of any
  constraints set in the provider configuration block itself;
- After all provider configurations are processed, iterate over the
  required_providers entries to ensure that any configuration-less
  providers are output to the JSON plan too.

No changes are necessary to the structure of the JSON plan output, so
this is effectively a semantic level bug fix.

3 Commits (bc31dbc179b04b277ca268dedd5f30fa83af90da)