Mount Consul ACL Token Volume with other containers in injected pods

[lawliet89]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request. Searching for pre-existing feature requests helps us consolidate datapoints for identical requirements into a single place, thank you!
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.

---

Is your feature request related to a problem? Please describe.

I am trying to "share" the Consul ACL token provided for Consul Connect via pod mutation with other containers in the pod (e.g. Consul Template).

I have created a new binding rule and corresponding role to bind new policies to the service tokens.

resource "consul_acl_binding_rule" "service_roles" {

  # TODO: Check if this is a hard-coded name
  auth_method = "consul-k8s-auth-method"
  description = "Bind service identities authenticated via Kubernetes to additional roles"
  selector    = "serviceaccount.name!=default"
  bind_type   = "role"
  bind_name   = "$${serviceaccount.name}"
}

Feature Description

Add a new annotation to mount the injected consul-connect-inject-data volume to other containers.

Use Case(s)

• Allow other users of Consul API (e.g. Consul Template) to share the same ACL token without also having to manage the lifecycle of the token.

Contributions

I can work on this if the maintainers think it's a good idea.

[lkysow]

1. I think that's a cool idea! What would the annotation look like? Would it be a list of the containers to share the token with?
2. If you override the binding rule you'll need to make sure you create a role ahead of time for every service in your cluster.

[lawliet89]

I think that's a cool idea! What would the annotation look like? Would it be a list of the containers to share the token with?

I was just thinking of something like consul.hashicorp.com/connect-inject-mount-data-volume that is either true or false. But if you think a comma separated list of containers is useful, I think that might be good too.

If you override the binding rule you'll need to make sure you create a role ahead of time for every service in your cluster.

The docs for the binding endpoint says that BindType=role - The computed bind name value is used as a RoleLink.Name field in the token that is created. This binding rule will only apply if a role with the given name exists at login-time. If it does not then this rule is ignored. I think this should be OK? I've not noticed any issues with services that do not have the role.

This is an additional binding rule that is also applied to the auth method as far as I can tell.

[lawliet89]

I've started a PR for this in #763

[lkysow]

I think this should be OK? I've not noticed any issues with services that do not have the role.

Ahh I think I just misunderstood. So you're only creating roles for certain services. The rest of them don't need the role and so they just don't get any additional permissions?

if you think a comma separated list of containers is useful

I think starting with a simple true/false that results in the token being mounted into every container is probably the simplest place to start.

[lawliet89]

Ahh I think I just misunderstood. So you're only creating roles for certain services. The rest of them don't need the role and so they just don't get any additional permissions?

Yep, you're right.

I think starting with a simple true/false that results in the token being mounted into every container is probably the simplest place to start.

The PR I linked accepts a comma-separated list of container names. It's not very hard to change it to a true/false implementation.