Notes from episode 70 of TGIK: Assuming AWS roles with kube2iam/kiam

Over the past few months I’ve been trying to learn everything there is to know about Kubernetes. Kubernetes is an amazing technology for deploying and scaling containers though it comes with a cost. It’s an incredibly complex piece of software and there are a ton of bells and whistles to become familiar with. One way that I’ve found for coming up to speed is Joe Beda’s weekly TGIK live broadcast. This occurs each Friday at 4PM EST and is CHOCK full of fantastic information. In episode seventy Joe discusses KIAM and Kube2IAM. You can watch it here :

Here are some of my takeways from the episode:

• The AWS metadata server exposes various attributes about the VM.
• The metadata server can be reached from the VM on the link local address http://169.254.169.254:
  $ curl http://169.254.169.254
• You can get your current identity with the aws simple token service get-caller-indentity option:
  $ aws sts get-caller-identity
• AWS roles can be assumed by a service or user via sts:AssumeRole.
• AWS vault allows you to access credentials during development https://github.com/99designs/aws-vault
• Roles contain two policies. Once defines who can assume it and the other contains what the policy can do.
• Trust relationships define who can assume a role
• The “Principal” in the trust relationship contains the list of ARNs that can assume this role.
• You can assume a role with the aws iam assume-role –role-arn arn://…../foo/bar –role-session-name foobar
• Kube2IAM intercepts calls to the metdata API server and proxies them to AWS.
• One downside to kube2iam is the need to attach every possible role to every worker.
• Kiam runs as a client / server. Server doles out roles and agent requests them.
• Kiam also works by interposing itself between the pod and the metadata server.

This article was posted by on 2020-01-27 01:00:00 -0500 -0500