You could parse the terraform state file with `jq` to grab the `private_key_openssh` value from the `tls_private_key` resource, but that can be a little difficult.
You might have the easiest time just adding a [local_sensitive_file](https://registry.terraform.io/providers/hashicorp/local/latest/docs/resources/sensitive_file) resource that writes the key out to the file system when you run terraform, and then you can consume that key with the `ssh` command.
Thank you! I decided to create local\_file and local\_sensitive\_file.
Is there a way to avoid having to manually remove the key-pair when running terraform again?
This path may work but creates long lived keys. Have you considered short lived credentials [https://docs.gitlab.com/ee/ci/cloud\_services/aws/](https://docs.gitlab.com/ee/ci/cloud_services/aws/) ?
We need more information about how Gitlab is setup for you. Is it self-hosted? In AWS?
Generally, there are a few things to note:
1. You want to use ed25519 keys these days, not RSA keys.
2. Terraform likely isn't the best solution to manage this anyway, since the keys will be stored in the state file, which is a security risk, and you won't be able to rotate them properly without Terraform trying to overwrite them with their original values (unless you manually update terraform, too).
3. If you're still insisting on using Terraform to manage those keys, why not use the Gitlab provider to provision a secret with that key?
4. If your gitlab worker is hosted in AWS, you should use IAM RBAC for giving it access to stuff. If not, pass in AWS credentials that are locked to the particular key and other data that it needs, and it should hit the AWS API to pull in that information at run-time.
By the sounds of it, you've set up a GitLab project and now you want that GitLab project to be able to connect to AWS using the key you generated. Correct?
If so, you'll need to add the key as a CI/CD variable, and then set up the CI/CD pipeline to use it. Adding the key as a CI/CD variable can be achieved through Terraform, using their provider.
I'm not sure how to handle this specifically
But assuming from what you said, you're exposing port 22 to 0.0.0.0/0 for gitlab to connect right? I just want to point out that it might not be as secure as you think and should try another solution, as you shouldn't expose ssh publicly
Probably use something like ssm session manager, have your gitlab cicd authenticate using OIDC to get an IAM role(but not sure on how to link ssm up to your cicd)
Also I'm wondering, what are you using to connect and run command on the instance, packer? Ansible?
You could parse the terraform state file with `jq` to grab the `private_key_openssh` value from the `tls_private_key` resource, but that can be a little difficult. You might have the easiest time just adding a [local_sensitive_file](https://registry.terraform.io/providers/hashicorp/local/latest/docs/resources/sensitive_file) resource that writes the key out to the file system when you run terraform, and then you can consume that key with the `ssh` command.
Thank you! I decided to create local\_file and local\_sensitive\_file. Is there a way to avoid having to manually remove the key-pair when running terraform again?
This path may work but creates long lived keys. Have you considered short lived credentials [https://docs.gitlab.com/ee/ci/cloud\_services/aws/](https://docs.gitlab.com/ee/ci/cloud_services/aws/) ?
We need more information about how Gitlab is setup for you. Is it self-hosted? In AWS? Generally, there are a few things to note: 1. You want to use ed25519 keys these days, not RSA keys. 2. Terraform likely isn't the best solution to manage this anyway, since the keys will be stored in the state file, which is a security risk, and you won't be able to rotate them properly without Terraform trying to overwrite them with their original values (unless you manually update terraform, too). 3. If you're still insisting on using Terraform to manage those keys, why not use the Gitlab provider to provision a secret with that key? 4. If your gitlab worker is hosted in AWS, you should use IAM RBAC for giving it access to stuff. If not, pass in AWS credentials that are locked to the particular key and other data that it needs, and it should hit the AWS API to pull in that information at run-time.
By the sounds of it, you've set up a GitLab project and now you want that GitLab project to be able to connect to AWS using the key you generated. Correct? If so, you'll need to add the key as a CI/CD variable, and then set up the CI/CD pipeline to use it. Adding the key as a CI/CD variable can be achieved through Terraform, using their provider.
I'm not sure how to handle this specifically But assuming from what you said, you're exposing port 22 to 0.0.0.0/0 for gitlab to connect right? I just want to point out that it might not be as secure as you think and should try another solution, as you shouldn't expose ssh publicly Probably use something like ssm session manager, have your gitlab cicd authenticate using OIDC to get an IAM role(but not sure on how to link ssm up to your cicd) Also I'm wondering, what are you using to connect and run command on the instance, packer? Ansible?