I’m attempting to add two missing resources to the Terraform Vault provider for configuring the Kerberos auth backend. However one of these resources, (which would model the auth/kerberos/config path), includes a required write-only attribute; the Kerberos keytab value. This value is not returned on a read.
I’m not sure exactly how to handle this in the provider code, normally I find another resource that behaves similarly and see what the code does however I haven’t come across another resource like this.
Does anyone have an example I can look at, or explain what I need to do to handle this? Presumably I just use the value from the existing state on reads. How would I handle an import scenario where the state doesn’t exist?
As @hQnVyLRx mentioned, there is upcoming work to support the idea of a “write-only” attribute in a managed resource that may fit your requirements here. Write-only would be the provider’s way of describing a configuration attribute that Terraform should not manage (no reading, only new values accepted from practitioner via config, etc.), which would always be stored in state as null. The current plan for write-only attributes that are “required”, is that the default validation of requiring a value will only be performed on Create during plan (rather than today’s Required, which is enforced during validate which has no access to prior state). That would be mean importing this resource with a write-only attribute (and providing no config value) would be valid even if the write-only attribute was Required.
Also, as of right now, we are planning on introducing write-only attribute support to SDKv2 as well as Plugin Framework, so you don’t need to worry about migrating the resource to take advantage of the eventual new functionality. (There are a lot of long existing resources in the major cloud providers that will benefit from this feature that are written in SDKv2, plus a majority of the work can be handled by the SDK itself, rather than the provider developer)
I’ll add a disclaimer that all of the above is actively in design/development, so it could change before release. There currently isn’t any Terraform core development done on write-only attributes so there is no way to test that PR linked ATM.
As for the options today, some initial thoughts
You could swap the Required to Optional and write a plan modifier that enforces the value be populated only during Create. This would allow you during import to just keep the keytab as null and the following refresh could just keep the prior state always (on import it would be null, otherwise it would be keeping the config value from the previous create). You could then opt to replace (destroy/re-create) whenever the keytab is changed (not sure if that was a part of your original plan or not).
If you’re importing this vault resource, would the practitioner know what the keytab is? If they enter a keytab in config after importing, then a destroy/re-create would be triggered, but perhaps that is expected?
Since the ImportID is an opaque string, if you can stringify the keytab into something like base64 you could just require that import IDs also include the keytab. With this approach you could keep the attribute as Required
The goal of import is to get a minimal stub state for a refresh to work properly, in this option we are saying that a keytab is required in state for a refresh to be successful for this resource.
You could just not support import! (not suggesting this is the right call, but always worth calling out the option )
,
)