terraform-provider-bigip

terraform-provider-bigip copied to clipboard

go-bigip seem to have the plumbing for this, but we don't have the resource for SSL profiles.

/cc @scshitole

I took a stab at these in a branch: https://github.com/pirotrav/terraform-provider-bigip

They do seem to work in general, but I'm very new to terraform so some descriptions may be off and there may be bugs or logical issues. But hopefully it's useful work anyway.

One 'bug' I am aware of is when creating SSL profiles that do not have certain variables set, the default checkboxes are overridden since fields seem to get pulled in as part of bigip.ClientSSLProfile and populated as null whether or not they are populated in terraform files. In my opinion this is undesirable but I have not found a way around it. If anyone has suggestions on that I would appreciate it. That also may be related to the go-bigip implementation more than anything, not certain yet.

I also have not written any tests yet, and have only tested with some local files in a QA environment, so use at your own risk.

Relevent files:

https://github.com/pirotrav/terraform-provider-bigip/blob/master/bigip/provider.go

https://github.com/pirotrav/terraform-provider-bigip/blob/master/bigip/resource_bigip_ltm_profile_ssl_server.go

https://github.com/pirotrav/terraform-provider-bigip/blob/master/bigip/resource_bigip_ltm_profile_ssl_client.go

Is there any update on when this feature will be released?

@jlosito I'll be back Tuesday and can update you then. Note that I do not work for f5 but my script appears to be feature complete and passes unit testing as well as my functional testing. I need to push the latest though again; I think what is on github in my branch is a bit out of date since I have made fixes. Also there is a known bug with client SSL in the go-bigip backend that I reported that f5 needs to fix. More thorough response to come. Pull request below shows the issue: https://github.com/f5devcentral/go-bigip/pull/27

@scshitole Any input on when this can be reviewed or merged? Also issue 27 is a clear bug and should be fixed as well (cipher case sensitivity). Apart from that clear defect, PUT vs PATCH is also an important distinction that should be made here and possibly in other places that have inheritance properties.

@jlosito , looks like this is merged into master. If you get the chance please test and let me know if you encounter any issues. Unit tests are in place and I did fairly comprehensive testing, but there are a lot of potential toggles so it would be good to hear any direct feedback as well.

Also again issue 27 above is still a concern. @scshitole , thanks for merging that change. Can you also take a look at this one (go-bigip repository): https://github.com/f5devcentral/go-bigip/pull/27

I believe that a PATCH rest method is more appropriate for profiles that support inheritance. Also the cipher case issue is a clear defect.

@pirotrav I just looked over the code and it looks awesome. Once I get a chance, I'm definitely going test it and run a terraform import for the certs which I had to upload and maintain through some non-Terraform scripts.

@hoffmanntravis, I have tested the resource and I came across a few errors (limited to my use case).

1. Missing attribute - "Session Ticket Timeout" under resource bigip_ltm_profile_client_ssl "retain_certificate" not recognised by TF
2. For the first build, the resource code works like a charm. I am able to create a PARENT profile which defaults from "clientssl" and then create child profile which defaults from the custom parent.

However, later when I try to add/modify other resources and apply the changes, TF plan shows, it will push the PARENT and CHILD SSL_profile resources as well, although there's nothing changed. This is undesired. If I apply the change now, I get an error back, probably stating that the chain certs are already present.

I have attached a screenshot of the resource below,

Hello @hoffmanntravis , the issue I reported still persists if I want to change the certificates.

Also, I notices, the provider stored the key passphrase in clear text, which is not secure. Is there any other way we can ensure the passphrase is not stored in clear text in the state file ?

@soumik612 Thanks for the detailed information. This should be coming up on our backlog soon, probably within a month I would guess. I'm thinking next sprint. I'll update when I have more information. I'll also take a look at the state file.

Hi, closing this request now. Please re-open if required or send an email to [email protected]. Thanks!