provider/aws: support custom endpoints for AWS EC2 ELB and IAM

[turkenh]

Allows to specify AWS Endpoints for EC2, IAM and ELB directly from .tf file like:

provider "aws" {
    access_key = "xxx"
    secret_key = "xxx"
    ec2_endpoint = "<ec2_endpoint_url>"
    elb_endpoint = "<elb_endpoint_url>"
    iam_endpoint = "<iam_endpoint_url>"
    insecure = "true"
    region = "us-east-1"
}

It also allows to disable HTTPS certificate check which is necessary for corporate solutions.

Solves #416 and #3974

[ecunal]

👍

[tugbabodrumlu]

👍

[kaskavalci]

👍

[onuryilmaz]

👍

[SchwarzM]

wow this would be nice

[radeksimko]

Although I probably personally won't need this, I'm in favour of such feature, except I'd change the DSL.

Keeping all of these options in the 1st level doesn't look very scalable. Imagine how many endpoints this list may grow up to. I'd rather see something like this:

provider "aws" {
    access_key = "xxx"
    secret_key = "xxx"
    endpoints {
        ec2 = "<ec2_endpoint_url>"
        elb = "<elb_endpoint_url>"
        iam = "<iam_endpoint_url>"
    }
    insecure = "true"
    region = "us-east-1"
}

[radeksimko]

Is it really optional? If it was, I guess a condition would be necessary here and below for each endpoint?

[turkenh]

If you do not set an endpoint, then, "c.IamEndpoint" is just an empty string here. And default value of config.Endpoint is also an empty string. So this is why I thought that there is no need for a condition here.

[radeksimko]

Ah, you're right.
That's quite elegant solution then.

[turkenh]

@radeksimko Regarding your above comment about the change in DSL, I can change my pull request like that. But currently there are two endpoint options already implemented, namely dynamodb_endpoint and kinesis_endpoint at the first level. So, I should also try to move them under "endpoints" block then, right?

[radeksimko]

currently there are two endpoint options already implemented, namely dynamodb_endpoint and kinesis_endpoint at the first level

Good point!

@catsby was merging #3255 and #2825 - what do you think about the DSL currently used VS proposed?

[afritzler]

+1

Any idea when this pull request will make it into the official release?

[catsby]

Hey Friends –

Terribly sorry about the silence here. I agree with @radeksimko in that the top level will not be sustainable, and a block format like he suggested is preferable.

We'd need to enable backwards compatibility with the current top level ones, however, so we'd have to support both.

If you could refactor to have at least the components you're suppling to use the block format, I can worry about the backwards compatibility. Or, if you're feeling super generous, feel free to tackle it 😄

Thanks so much! I apologize again for the delay here. Let us know what you think

[turkenh]

@catsby and @radeksimko, I moved the endpoints added with this PR under "Endpoints" block.
Did not touch previously added ones not to break something :)

[catsby]

Hey Friends – I just merged #5114 which is this PR but rebased on master, so I'm closing this. Thanks for all the work!

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.