Feature request: Support secret creation for github actions

[gjambet]

Hi friends,

it would be super cool to be able to set secrets for actions through terraform while creating a repository. ;)

ty,

g. (happy action user)

[hronix]

Yes please

[zzh8829]

github hasn't made api for secrets available yet, we have to wait for now

[iniinikoski]

Hi. Any updates on this - is the Secrets API still private...?

[gjambet]

❤️

[jcudit]

GitHub is aiming to make this endpoint available within the next few sprints. Mention me here if I don't post an update in a month or so.

[ajliv]

Secrets have been added to the GitHub API https://developer.github.com/v3/actions/secrets/

[martinssipenko]

We now need to wait till Go GitHub client releases action secrets - google/go-github#1402

[bkamin29]

+1

[btkostner]

It looks like it was merged google/go-github#1402 (comment) and released in the v29.0.3 tag.

[martinssipenko]

I think we should also wait for #342 before we start implementing this one.

[martinssipenko]

What do we think about usage? Should action secrets be a new resource - github_repository_action_secret and be used as follows?

resource "github_repository_action_secret" "foo" {
    repository = "${github_repository.repo.name}"
    name       = "FOO"
    secret     = "plain secret"
}

[hazcod]

Is there a way to provide ciphertexts in terraform and supply the key via an environment variable?
I can imagine it's problematic to store plaintext github secrets in terraform files ... which might be located on github again.

[martinssipenko]

@hazcod I think one option would be that resource accepts two conflicting arguments - secret and encrypted_secret, The secret could be used to pass plain text value which would be encrypted by terraform using GitHubs public key. The encrypted_secret would accept already encrypted value and leave the encryption to the user.

Off topic: In order to not store secrets in terraform files I use an approach where I store secrets somewhere else, and then use a data provider to get the secret values from there. In that case I only need to reference the value from data source in my TF resources. Secrets are managed manually.

[martinssipenko]

@radeksimko @jcudit @paultyng what are your thoughts on this?

[tgermain]

Note for the implementation: how to know if a secret has been changed and need to be updated by terraform ?

The secret API does not offer a way to read the content of a secret (normal) but return the created_at and updated_at date.

Should we store at least the updated_at date in terraform state and when we refresh terraform state (before a plan for instance) we get the secret and compare its update_at date with the one in the state.
A difference in those dates would indicate the secret was updated since the last time terraform interact with. What do you think?

[martinssipenko]

Another option is that terraform does not detect and repair "drift" on this resource in case the data is updated or deleted outside of Terraform. I think it might also be possible to not store secrets in state, but instead store a hash value of the secret, in case current value hash does not match hash stored in state an update should be performed.

[StephenWithPH]

A lurker (who wants this feature) chiming in...

I suggest not trying to get too clever regarding secrets in state. I often treat the Terraform Vault Provider as a guide for the official-ish Hashicorp way of doing things in Terraform.

Interacting with Vault from Terraform causes any secrets that you read and write to be persisted in both Terraform's state file and in any generated plan files. For any Terraform module that reads or writes Vault secrets, these files should be treated as sensitive and protected accordingly.

(https://www.terraform.io/docs/providers/vault/index.html)

Directly on the label, they disclaim any cleverness to protect secrets.

I think Terraform core offers enough ways to protect secrets. The combination of using remote state and an encryption-enabled backend seems sufficient. See https://www.terraform.io/docs/state/sensitive-data.html.

[tgermain]

Indeed @StephenWithPH , state is already sensitive so we do not have to be too clever using hash in state (instead of plaintext values).

Another option is that terraform does not detect and repair "drift" on this resource in case the data is updated or deleted outside of Terraform.

This is also fine if it is clearly mentioned in the doc of the resource.
In case of doubts, you can always taint the doubtful resource in your terraform and recreate it. Terraform is your source of truth so manuals changes outside of it should be committed in terraform if they are meant to be permanent.

[senare]

Nice to see that this is being worked on!

imho ... just get it done ... KISS

[benj-fletch]

Hi, I'd like to take on this as we have a requirement for it in our organisation.
I think that we'd need to merge in https://github.com/terraform-providers/terraform-provider-github/pull/342 before work can be undertaken here, however, since v29 of go-github contains the calls we would need to utilise.
If it's ok, I'll start work on this in a branch of master merged with https://github.com/terraform-providers/terraform-provider-github/pull/342 and we can go from there?

[martinssipenko]

@benj-fletch if you need any help, feel free to ask me.

[benj-fletch]

@martinssipenko Thanks!
I think from reading the above comments I'll keep it relatively simple and allow the user of the resource to protect their secrets as they see fit (where possible). I need to see what is available to configure on the API and work on that basis.
EDIT: I'll be making changes here for those interested in tracking progress.

[jcudit]

@benj-fletch my only ask on this one is to try to keep things forward compatible with these related enhancements. I'm 👍 on designing for overall Actions support rather than just the secret functionality.

[benj-fletch]

@jcudit Sure thing, I will try my best to do so!

[techjacker]

Any idea when this will get merged? Would be very handy feature

[benj-fletch]

I believe that this ticket can be closed now, following the merge of #362 ?