Use a DynamoDB table to coodinate state locking in S3.
We use a simple strategy here, defining a key containing the value of
the bucket/key of the state file as the lock. If the keys exists, the
locks fails.
TODO: decide if locks should automatically be expired, or require manual
intervention.
This commit enables terraform to utilise the assume role functionality
of sts to execute commands with different privileges than the API
keys specified.
Signed-off-by: Ian Duffy <ian@ianduffy.ie>
* Skip IAM/STS validation and metadata check
* Skip IAM/STS identity validation - For environments or other api
implementations where there are no IAM/STS endpoints available, this
option lets you opt out from that provider initialization step.
* Skip metdata api check - For environments in which you know ahead of
time there isn't going to be a metadta api endpoint, this option lets
you opt out from that check to save time.
* Allow iam/sts initialization even if skipping account/cred validation
(#7874)
* Split out skip of IAM validation into credentials and account id
(#7874)
The state is always JSON, in spite of the fact that this interface
presents it as an opaque byte array. It's more helpful to those interacting
with the state object outside of Terraform for it to have a more specific
content-type.
This change allows the user to specify `-backend-config="encrypt=1"`
to tell S3 to encrypt the data that's in the bucket when using S3
for remote config storage.
The encryption uses "Amazon S3-managed encryption keys" so it should
not require any further user intervention.
A line was added to the unit test just for coverage.
The acceptance test was modified to:
a) Use encryption
b) Push some test data up to the bucket created to ensure
that Amazon accepts the header.
This landed in aws-sdk-go yesterday, breaking the AWS provider in many places:
3c259c9586
Here, with much sedding, grepping, and manual massaging, we attempt to
catch Terraform up to the new `awserr.Error` interface world.
James Bardin