In the last blog, we talked about why proper management is important for AWS IAM which is not only related to security but also paves an appropriate way of handling things.
Now we’ll discuss some approaches to manage IAM, how these approaches/practices will affect access management and by using an example, we will also discuss how we can include these practices in the existing or new setup. Let’s jump into these approaches and discuss these practices one by one.
Whenever someone says orchestration for microservices, the first thing that usually comes to mind is Kubernetes. I believe that’s normal. I used to think the same but then I came across an interesting scenario that changed the way I used to think about microservice orchestration completely.
Usually, people think microservices mean containers, hence they build their application in a cloud-native approach so that it can easily run on any platform using the containerized approach. Well, I agree that containerization is a decent way of designing a cloud-native application especially when we integrate it with orchestrators like Kubernetes or OpenShift. It takes away a lot of overhead from us like:- scaling, failover, deployment, etc but it doesn’t imply that microservices can only be managed inside a containerized ecosystem. Microservice is an ideology or mindset for designing the application and containerization is a power-up that supports the ideology.
When we talk about security, AWS IAM is one of the most fundamental & critical AWS service which needs suitable observation to design it because any careless & negligible exercise leads to huge complication & misshaping. AWS IAM is one of a kind which is ignored at the starting means not organise properly which leads to enormous complications while managing access to resources. Most of the time, a proper technique of managing AWS IAM access is ignored or doesn’t documented or configured properly due to which team has to change the IAM management format every time when there is a new requirement or modification.
Earlier, while writing deployment files in k8s, I found that the pods were getting scheduled in any random node. The pods of small deployments got scheduled in large nodes, due to which large deployment pods were staying in a pending state. Therefore, I had to delete the small deployment pods, so that the large deployment pods could get scheduled in that particular node.
One day, I decided to get rid of this problem. While looking for a solution and exploring about Kubernetes, I got to know about Node taints and pod tolerations in Kubernetes. Here, in this blog, I’ll talk about node taints and pod toleration and how we can use it with nodeselector in kubernetes deployments.