It appears that the cacert option for the winrm provisioner was
not getting passed correctly to the winrm package. Log output
showed that CACert was false regardless of configuration.
While the validation of the connector looked for cacert, the winrm
communicator looked for ca_cert.
Now that we are looking into the CLI config file for service host
credentials, it's important to support multiple separate files so that
users can keep credentials separate from other settings and credentials
for different hosts separate from one another.
There is no restriction on which settings can appear in which locations.
This is up to the user to decide, depending on their security needs and
e.g. on whether certain files are generated vs. manually-edited.
Previously we handled all of the config sources directly within the main
function. We're going to make CLI config loading more complex shortly, so
having this encapsulated in its own function will avoid creating even more
clutter inside the main function.
Along the way here we also switch from using native Go "error" to using
tfdiags.Diagnostics, so that we can potentially issue warnings here too
in future, and so that we can return multiple errors.
We require that each "credentials" block has a valid hostname and that
there be no more than one "credentials_helper" block.
There are some more sophisticated validations we could do here, such as
checking if the same host is declared more than once, but since this
config handling will be rewritten to use HCL2 in the near future, and this
sort of check is easier to do in the HCL2 API, we just check the basic
stuff for now and plan to revisit later.
Fixes#15921
When terraform re-creates an existing node/client with chef provisioner,
the already existing client (which has old keys) must be removed from
the vault items. Afterwards, the chef-vault will be updated with the
newly created client (which has the new keys). Therefore, the recreated
client will be able to decrypt the vault items properly.
Update all references to the version values to use the new package.
The VersionString function was left in the terraform package
specifically for the aws provider, which is vendored. We can remove that
last call once the provider is updated.
Many terraform project packages now want access to the current terraform
version information. Since most packages end up being consumed by the
core terraform package, preventing import cycles becomes difficult.
This uses an in-memory table of credentials keyed on hostname. This is
the simplest possible credentials source that can actually return
credentials, and is suitable for representing statically-configured
credentials from configuration.
The command package is the main place we need access to these, so that
we can use them during init (to install packages, for example) and so that
we can use them to configure remote backends.
For the moment we're just providing an empty credentials object, which
will start to include both statically-configured and
helper-program-provided credentials sources in subsequent commits.
For situations where no credentials are needed but where a working
CredentialsSource is still required, this variable provides a convenient
way to get a fully-functional-but-empty credentials source.
Although service discovery metadata is usually not sensitive, a service
host may wish to produce different results depending on the requesting
user, such as if users are migrating between two different implementations
that are both running concurrently for some period.
This credentials source wraps another and caches its results in memory
in a map that is keyed on the request hostname.
This should ease the common case of many services operating on the same
hostname by allowing an initial set of credentials to be re-used for
subsequent requests.
This CredentialsSource can serve as an extension point to pass credentials
from an arbitrary external system to Terraform. For example, an external
helper program could fetch limited-time credentials from HashiCorp Vault
and return them, thus avoiding the need for any static configuration to
be maintained locally (except a Vault token!).
So far there are no real programs implementing this protocol, though this
commit includes a basic implementation that we use for unit tests.
This function deals with turning a map derived from some user input
(e.g. in a config file) into a HostCredentials object, if possible. This
will be used as a standard way to specify credentials so we have a place
to add new credentials types in future and have support for those across
all of our map-based CredentialsSources.
This package implements our Terraform-native Service discovery protocol,
which allows us to find the base URL for a particular service given a
hostname that was already validated and normalized by the svchost package.
We're starting to expose a number of so-called "Terraform-native services"
that can be offered under a friendly hostname. The first of these will
be module registry services, as they expand from the public
Terraform Registry to private registry services within Terraform
Enterprise and elsewhere.
This package is for wrangling these "friendly hostnames", which start
their lives as user-specified unicode strings, can be converted to
Punycode for storage and comparison, and can in turn be converted back
into normalized unicode for display to the user.
In order to parse provider, resource and data source configuration from
HCL2 config files, we need to know the relevant configuration schema.
This new method allows Terraform Core to request these from a provider.
This is a breaking change to this interface, so all of its implementers
in this package are updated too. This includes concrete implementations
of the new method in helper/schema that use the schema conversion code
added in an earlier commit to produce a configschema.Block automatically.
Plugins compiled against prior versions of helper/schema will not have
support for this method, and so calls to them will fail. Callers of
this new method will therefore need to sniff for support using the
SchemaAvailable field added to both ResourceType and DataSource.
This careful handling will need to persist until next time we increment
the plugin protocol version, at which point we can make the breaking
change of requiring this information to be available.
Having a reference to the originating source range will allow us to
generate decent error messages if certain references can't be resolved
at interpolation time.
This is not yet populated or used. It will never be populated nor used by
the current HCL/HIL-based interpolation path, but will be used by the
experimental HCL2-based interpolation path to give it the necessary info
to produce diagnostics.
The value-conversion machinery is also needed in the main "terraform"
package to help us populate our HCL2 evaluation scope, so a subset of the
shim functions move here into a new package where they can be public.
Some of them remain private within the config package since they depend
on some other symbols in the config package, and they are not needed
by outside callers anyway.
Previously we were showing only the summaries when converting to a string
error, but HCL generates summaries that indicate only the _type_ of error,
expecting that the detail will give the details, and so we need to show
both in order to produce a useful error message.
This launches Terraform inside a headless dlv configured to accept a
remote debugging process. It's configured this way so it can be easily
used from a debugger GUI integrated into an IDE/editor, but it can also
be used from the CLI by running the command it prints.
Using a remote debugger here is useful even when debugging with the CLI,
since it keeps Terraform's verbose and colorful output from interfering
with the debugger UI.
This new version supports a conversion from object types to map types,
which is important for Terraform because HCL2 { ... } syntax produces
objects but lots of Terraform attributes require maps.
HCL will be the most frequent origin of a source range, so this helper
should make it easier to translate these between the two worlds so we
can more easily use them in native Terraform diagnostics and other
messaging.
Uses Levenshtein distance to decide if the input is similar enough to one
of the given suggestions, and returns that suggestion if so.
The distance threshold of three was arrived at experimentally, and has
no objective basis.
JJ Asghar