Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Service Account secret values #241

Closed
Stelminator opened this issue Dec 5, 2018 · 2 comments · Fixed by #243
Closed

Feature Request: Service Account secret values #241

Stelminator opened this issue Dec 5, 2018 · 2 comments · Fixed by #243

Comments

@Stelminator
Copy link
Contributor

Stelminator commented Dec 5, 2018

Hi,

I'd like to be able to extract a service account token from a cluster (or generate an appropriate one if possible) to be used as a bearer token.

I'm willing to help create the datasource mentioned below, but could use a sanity check that it's actually a missing feature before I put a bunch of time into that. Additionally, if there's a better way to accomplish the goal, I'd very much appreciate hearing it.

Thanks!

Use case

I'm trying to create a prometheus config that could work from outside of a Kubernetes cluster (really, from inside a separate one) and can be automatically generated from terraform outputs of other projects. I'm trying to provide monitoring as a service while putting the minimal burden for other developers managing their own apps.

To accomplish that, I've found this gist which should give me enough to make the scrapes work if I have the endpoint and the token. The endpoint is easy, but creating a service account and then being able to use it outside the cluster seems to be the missing piece; specifically, access to the Secret data.

Affected Resource(s)

  • kubernetes_service_account
  • kubernetes_secret

Terraform Configuration Files

maybe something like this:

resource "kubernetes_service_account" "example" {
  metadata {
    name = "terraform-example"
  }
  secret {
    name = "${kubernetes_secret.example.metadata.0.name}"
  }
}

data "kubernetes_secret" "example" {
    name = "${kubernetes_service_account.example.default_secret_name}
}

output "service_account_data" {
     value = "${data.kubernetes_secret.example.data}"
}

Expected Behavior

Ability to provide service accounts for access to the Kubernetes API from outside the cluster.

Actual Behavior

We don't seem to have that.

References

@Stelminator
Copy link
Contributor Author

sidenote: https://github.com/Ashald/terraform-provider-yaml will probably do nicely to parse what I want from the secret data.

Stelminator added a commit to Stelminator/terraform-provider-kubernetes that referenced this issue Dec 5, 2018
adds data_source_kubernetes_secret

hashicorp#241

example use case:
```
resource "kubernetes_service_account" "example" {
  metadata {
    name = "terraform-example"
  }
}

data "kubernetes_secret" "example" {
  metadata = {
    name      = "${kubernetes_service_account.example.default_secret_name}"
    namespace = "${kubernetes_service_account.example.metadata.0.namespace}"
  }
}

output "token" {
  value = "${lookup(data.kubernetes_secret.example.data, "token", "")}"
}
```
@Stelminator
Copy link
Contributor Author

Stelminator commented Dec 5, 2018

I have the start of a PR that does what I want:
#243
needs tests, but:

resource "kubernetes_service_account" "example" {
  metadata {
    name = "terraform-example"
  }
}

data "kubernetes_secret" "example" {
  metadata = {
    name      = "${kubernetes_service_account.example.default_secret_name}"
    namespace = "${kubernetes_service_account.example.metadata.0.namespace}"
  }
}

output "token" {
  value = "${lookup(data.kubernetes_secret.example.data, "token", "")}"
}

Edit: added tests.

alexsomesan pushed a commit that referenced this issue Dec 13, 2018
adds data_source_kubernetes_secret

#241
@ghost ghost locked and limited conversation to collaborators Apr 21, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant