The default network-based discovery is not desirable for all situations,
so this mechanism allows callers to provide a services map for a given
hostname that was obtained some other way (caller-defined) which will then
cause network-based discovery to be skipped and the given map to be
returned verbatim.
We encourage users to share the "terraform version" output as part of
filing an issue, but previously it only printed the core Terraform version
and this left provider maintainers with no information about which
_provider_ version an issue relates to.
Here we make a best effort to show versions for providers, though we will
omit some or all of them if either "terraform init" hasn't been run (and
so no providers were selected yet) or if there are other inconsistencies
that would cause Terraform to object on startup and require a re-run of
"terraform init".
Two different errors here caused this test to pass even though it was
incorrect: the wanted version string was incorrect, but the test for it
was also inverted, and so together this made the test pass even though
it was actually not testing the output at all.
Removed some of the test cases that we don't allow in the svchost
package. Will check back if those are needed in the registry and work
around them as necessary.
For the same reason the disco tests need to override the http.Transport,
other test fixtures will need to as well. Provide a field to override
the default httpTransport.
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.
Martin Atkins