jsonplan and jsonstate: include sensitive_values in state representations#28889
jsonplan and jsonstate: include sensitive_values in state representations#28889mildwonkey merged 2 commits intomainfrom
Conversation
|
did you read my mind? |
|
|
||
| // SensitiveValues is similar to AttributeValues, but with all sensitive | ||
| // values replaced with true, and all non-sensitive leaf values omitted. | ||
| SensitiveValues map[string]bool `json:"sensitive_values,omitempty"` |
There was a problem hiding this comment.
By using a map[string]bool here I think we reduce the granularity of sensitivity when compared to the precise level used in change representation (which uses a json.RawMessage for BeforeSensitive/AfterSensitive). This means that for the following config:
resource "null_resource" "none" {
triggers = {
boop = "beep"
flap = sensitive("honk")
}
}the sensitive_values output would be {"triggers":true} rather than {"triggers":{"flap":true}}. As a result, a state renderer would have to hide the entire triggers attribute, rather than just the one sensitive member.
This is compatible with the JSON plan sensitivity output, just more coarse. Is that necessary or could we consider keeping the full sensitivity information?
There was a problem hiding this comment.
🤔 you're absolutely correct, that ain't right, I shall fix that.
…ions A sensitive_values field has been added to the resource in state and planned values which is a map of all sensitive attributes with the values set to true. It wasn't entirely clear to me if the values in state would suffice, or if we also need to consult the schema - I believe that this is sufficient for state files written since v0.15, and if that's incorrect or insufficient, I'll add in the provider schema check as well. I also updated the documentation, and, since we've considered this before, bumped the FormatVersions for both jsonstate and jsonplan.
mildwonkey
force-pushed
the
mildwonkey/show-state-sensitive
branch
from
dc5de76 to
f18e035
Compare
…ions (#28889) * jsonplan and jsonstate: include sensitive_values in state representations A sensitive_values field has been added to the resource in state and planned values which is a map of all sensitive attributes with the values set to true. It wasn't entirely clear to me if the values in state would suffice, or if we also need to consult the schema - I believe that this is sufficient for state files written since v0.15, and if that's incorrect or insufficient, I'll add in the provider schema check as well. I also updated the documentation, and, since we've considered this before, bumped the FormatVersions for both jsonstate and jsonplan.
…ions (#28889) * jsonplan and jsonstate: include sensitive_values in state representations A sensitive_values field has been added to the resource in state and planned values which is a map of all sensitive attributes with the values set to true. It wasn't entirely clear to me if the values in state would suffice, or if we also need to consult the schema - I believe that this is sufficient for state files written since v0.15, and if that's incorrect or insufficient, I'll add in the provider schema check as well. I also updated the documentation, and, since we've considered this before, bumped the FormatVersions for both jsonstate and jsonplan.
|
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. |
4 participants
A sensitive_values field has been added to the resource in state and planned values which is a map of all sensitive attributes with the values set to true. To achieve this, I stole and exported the
sensitiveAsBoolfunction that was injsonplan(it had to be moved to jsonstate to avoid import cycles).It wasn't entirely clear to me if the values in state would suffice, or if we also need to consult the schema - I believe that this is sufficient for state files written since v0.15, and if that's incorrect or insufficient, I'll add in the provider schema step as well.
I also updated the documentation, and, since we've considered this before, bumped the FormatVersions for both jsonstate and jsonplan.