add "ca_file" option to the elasticstack provider

[utilitynerd]

allows connecting to an elasticsearch cluster using a custom certificate authority.

I know just enough go to get myself in trouble, but figured I would try to solve my own problem anyways. resolves #34

It adds the "ca_file" parameter to the elasticstack provider. If ca_file is set, the certificate is read and its contents are added to the CACert field in the elasticsearch.Config struct.

[elasticmachine]

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

[cla-checker-service]

💚 CLA has been signed

[Kushmaro]

Thanks so much for putting up the first community PR @utilitynerd , I have to ask though - is there a specific reason for not implementing "insecure=true" like mentioned in the issue? that would be the direction we'd like to take to resolve this one.

Specifying a root_ca file is often quite cumbersome, and doesn't add much value in TF as it does on browsers for example (where browsers will show if a cert is trusted or not)

[olksdr]

Hey @utilitynerd,
Thanks for your contribution!

There are few more steps to get this over and get merged:

• things we're also support the per elasticsearch-resource elasticsearch_connection block, we will need to add ca_file in there as well, see

  terraform-provider-elasticstack/internal/utils/utils.go

  Lines 124 to 149 in f0c6a1f

  	Elem: &schema.Resource{
  	Schema: map[string]*schema.Schema{
  	"username": {
  	Description: "A username to use for API authentication to Elasticsearch.",
  	Type: schema.TypeString,
  	Optional: true,
  	RequiredWith: []string{"elasticsearch_connection.0.password"},
  	},
  	"password": {
  	Description: "A password to use for API authentication to Elasticsearch.",
  	Type: schema.TypeString,
  	Optional: true,
  	Sensitive: true,
  	RequiredWith: []string{"elasticsearch_connection.0.username"},
  	},
  	"endpoints": {
  	Description: "A list of endpoints the Terraform provider will point to. They must include the http(s) schema and port number.",
  	Type: schema.TypeList,
  	Optional: true,
  	Sensitive: true,
  	Elem: &schema.Schema{
  	Type: schema.TypeString,
  	},
  	},
  	},
  	},

  so this way we will stay consistent in all the places, and then you can update code in

  terraform-provider-elasticstack/internal/clients/api_client.go

  Lines 123 to 135 in f0c6a1f

  	if u := conn["username"]; u != nil {
  	config.Username = u.(string)
  	}
  	if p := conn["password"]; p != nil {
  	config.Password = p.(string)
  	}
  	if endpoints := conn["endpoints"]; endpoints != nil {
  	var addrs []string
  	for _, e := range endpoints.([]interface{}) {
  	addrs = append(addrs, e.(string))
  	}
  	config.Addresses = addrs
  	}

  to read the newly added option
• after changes are maybe, the docs must be updates as well, you can run make gen command which will re-generate the docs and adds this options as well
• and one more step is you will have you sign the Contributor Agreement for the account you're pushing your commits from, in this case it looks like the commit is coming from https://github.com./mikejones-ucb

Once this is done we can once more go over the PR and see if there are any missing things to be added.

Thanks again for your contribution!

[olksdr]

Suggested change

	})
	})
	return nil, diags

It would be great if we immediately return the diags here to report the error sooner.

[utilitynerd]

Thanks for the feedback!

I'm not opposed to the "insecure=true" method instead of validating against a custom cert. Although maybe it would be nice to eventually have both options available.

Since it sounds like the project would prefer the insecure route, why don't I take your suggestions and see if I can put together a separate PR implementing it.

[Kushmaro]

@utilitynerd thank you so much. We've actually discussed internally after our discussion here, and decided to allow for both options.

So again, really a lot of appreciation for these 2 PRs

[utilitynerd]

I believe I've addressed the issues above:

• return early if loading the ca_file results in an error
• added the ca_file parameter to the elasticsearch_connection block
• generated updated documentation
• signed the contributor agreement with my other username

Let me know if there is anything else

[olksdr]

jenkins test this please

[olksdr]

@utilitynerd please, merge main into your branch and resolve the conflicts which are coming from #36

[olksdr]

ok to test

[olksdr]

lgtm