Bind IAM credentials to ServiceAccounts, not directly to Pods

[emmanuel]

From a logical standpoint, I believe it is clearer and better aligned with Kubernetes' security primitives to associate IAM credentials with a service account, rather than directly with a Pod. Specifically, this would mirror how Kubernetes' tokens are automatically mounted into the Pod filesystem, based on the associated ServiceAccount[1].

I don't (yet) have a good idea about how to associate an IAM role with a ServiceAccount. We currently rely on the Namespace restriction annotation to limit the IAM roles that are allowed to be assumed by the Pods within a Namespace. Because we are running a multi-tenant cluster, we cannot allow users to assume every role. At the moment, I'm not sure how to associate an IAM role with a ServiceAccount in a way that both 1) allows users to maintain their own SAs, and 2) prevents users from binding arbitrary/disallowed IAM roles.

Thoughts?

[1] This also parallels Istio's use of the ServiceAccount as the basis/binding point of workload identity: https://github.com/istio/auth#identity

[emmanuel]

Well I guess I was confused, because it now appears obvious that the annotation-based approach that kube2iam uses today translates directly to an SA-oriented model simply by relocating the annotations from pods to SAs.

[jrnt30]

That's a cool idea that I could see being valuable .

My assumptions would be:

• Flags --enable-pod-annotations & --disable-pod-anntoations be added to Kube2IAM that indicates if a direct pod annotation can be respected/used. By default, the --enable-pod-annotations would be set to true for backwards compatibility.
• By default, if a SA and Pod both have the annotation, the Pod's annotation still wins
• Namespace restrictions apply to the SA mapping as well.
• If a --default-role is provided, this will only be assessed if all explicitly enabled sources are empty

If that makes sense, I may start hacking on that.

[emmanuel]

@jrnt30 Sounds good overall (and I'm glad that you find the idea interesting/useful). I would propose that the enable/disable flags be collapsed into a boolean:

--pod-annotations=true

With true as the default value to preserve current value unless the operator opts-in to the ServiceAccount-based interaction.

[emmanuel]

Alternately (and maybe I'm just confusing things now), the flag could be structured as --service-account-annotations=false, where the default value would be false in order to preserve existing behavior by default. I think this would be (marginally) clearer than basing the flag around pod annotations (given that pod annotations are the existing/default behavior).

WDYT @jrnt30? Also, WDYT @jtblin?

[jescarri]

are both mechanisms going to coexist? I have a pod with an annotated SA and another pod without SA but with the pod annotation set.

[emmanuel]

I think I misunderstood your initial proposal. Do you mean that the --enable-pod-annotations flag would be additive to the service account annotation functionality? If so, then I misunderstood you.

Thinking about this again, supporting one or both of Pod and ServiceAccount annotations would be desirable, especially during a transition between the two. Therefore, I propose two flags: --pod-annotations=true/false and --service-account-annotations=true/false. One of the two must be true, and both may be true. This would allow only Pod annotations, only ServiceAccount annotations, or either/both. In the event both flags are true and a Pod has both a kube2iam annotation and an annotated ~SeeviceAccount~ ServiceAccount, I think the best plan would be to honor the Pod annotation and ignore the ServiceAcoount annotation (to limit changes to current behavior).

How does that sound @jrnt30 and @jescarri?

[jtblin]

Sounds good to me. Having separate flags for pod and service accounts seem to be the best approach.

That said, before starting on this, I'd like to fix the default role race condition, see this comment (leaning towards option 2). After the index informer PR is merged obviously :)

[jescarri]

sounds good to me!.

[pfremm]

I definitely agree with service accounts being preferred. I also see benefits of a CRD where you bind service accounts to a list of roles. Basically use as much of the RBAC concepts from kubernetes as possible in the solution.

[razaj92]

Is this something that is planned for implementation?

Much prefer the idea of being able to annotate Service Accounts the same way as Pods