Closed david-woodruff closed 4 years ago
Not tracking the secret key is a good point. I'm wondering if it would be good enough to allow the user to be created, then I can also attach any policies with Terraform, as well as any related infrastructure. The only manual step would be an immediate key rotation in the console? I don't really consider the access key and secret key to be infrastructure anyway (although I suppose you could argue that it could be).
The big win is that I can define everything in one run instead of the process now where I have to manually create the user before I can run the rest of my Terraform (like attaching policies to the user).
If the User is created via Terraform, there can always be a local-exec that uses the ALKS CLI to generate the AccessKey and Secret key for the user to be used elsewhere
I started to work on this feature but discovered that there is no API endpoint available to list existing LTKS or get their details. Without this we cannot sync remote state so we cant build this yet.
@ekozlowski can you look at getting these endpoints added?
The Internal Tools team has discussed this and the endpoint - we have a couple stories for implementing the List LTK endpoint, as well as to implement the LTK endpoints in the TFProvider in a way that doesn't expose key info to the state files.
As an update, we have added an endpoint for handing the LTKs, and have begun discussing the TFP implementation.
I would like to see this feature implemented as well.
Regarding the "secrets in state file" concerns: Our remote state files are kept in S3 and are encrypted. However, if the ALKS provider does not offer a way to generate these keys with a resource
, then I think my only option would be to generate the LTK out-of-band and pass it as a var
to my Terraform configuration, which I think is likely to result in those vars
getting captured in a state file somewhere anyway. Also, we already have Terraform managing and generating RDS databases, and those credentials are definitely in the remote state file, so I guess what I'm saying is that this doesn't sound like a show-stopping blocker to me.
In any case, I need to generate some LTKs for a legacy, on-premise application that is slowly being migrated to AWS. The configuration for this application is kept in an .ini
file stored in, you guessed it, GitHub, so the security implications of having those LTKs in a remote state file are even more moot for my use case.
Having nullified the concern over keeping the LTK in a state file, the remainder of my choice is between provisioning LTKs manually with the ALKS CLI, or automating it with infrastructure-as-code. I know which option I would prefer, so I hope to see this feature soon!
This has been implemented in this PR: https://github.com/Cox-Automotive/terraform-provider-alks/pull/85
Add LTK Service to TF Provider
https://alks.coxautoinc.com/swagger-ui.html#/long45term45key45rest45service
We don't wan't the Access Key and Secret key to get tracked in any state files, so we might have to get creative.
A force destroy flag might be beneficial as well to be included. https://www.terraform.io/docs/providers/aws/r/iam_user.html#force_destroy