Image for post
Image for post

It’s been said that “Beauty is only skin-deep”. However, I think ugly comes from deeper inside us. And, for decades we have been quite ugly towards each other, based on the superficialities of our beliefs, our chosen affiliations, and even our skin-color. For goodness sakes, our skin-color? Something over which we have absolutely no control drives how we feel about others? This sort of ugliness takes effort. It’s a choice.

Our ugliness towards each other is our shared weakness. We own that, and it is not due to any single person or association, including a political party. It is also not due to skin-color. Our propensity for ugliness is catalyzed primarily by our propensity to mainly exist in our respective comfort zones and echo chambers. If we erroneously judge folks on superficial aspects, like skin-color or beliefs, then we miss out on so much. And, we enable ourselves to make the inevitable incorrect assumptions about others. …

Image for post
Image for post

Over a decade ago I worked for a former Marine officer. He was a quiet, intelligent, and very capable leader, with a firm grasp of human nature. He didn’t subscribe to hyperbole; feelings were not facts. He was biased for action. His quiet and direct demeanor was off-putting, if not unnerving to some. I realized later that his style was refreshing and constructive.

I learned/relearned several things from my former boss. Some of those lessons are:

Image for post
Image for post

As we migrate applications running in AWS to containers and Kubernetes we also need to accommodate each application’s AWS permissions, as supplied by roles. If the applications assume AWS IAM roles that allow them to perform AWS operations, these roles should still work inside Kubernetes running inside AWS. At issue is how we allow pods to assume needed roles for which they are authorized, while not permitting pods to assume roles for which they are not authorized.

When running Kubernetes in AWS we’re fortunate to be able to choose between two mature AWS role-assumption solutions: kiam and kube2iam. Both of these solutions allow Kubernetes pods to assume AWS IAM roles, provided that the appropriate underlying Kubernetes node role is trusted by the target role that is needed by the pod. In kiam, the node role that needs to be trusted is that of a master node. In kube2iam, it is the role assumed by the node on which the pod is running. Both solutions act like proxies to perform the sts:AssumeRole operation in AWS. Since running containers are actually Linux processes, containers can make the needed AWS EC2 metadata calls to get credentials based on roles assumed by the cluster node. …


Jimmy Ray

Cloud and Containerization SME

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store