Understanding the roles of Workload Identities, Cluster Service Accounts, IAM Policies, and IAM Roles in managing access controls within AWS environments.
Exploring real-world use cases to illustrate the importance of effective IAM policy management in securing multi-tenant environments and aligning access controls with business requirements.
Comparing manual IAM policy management with streamlined approaches, such as Wayfinder's Package Workload Identities, to highlight the benefits of automation and centralised policy management.
This article was first published on ITProPortal on 10 March 2020
GitOps first hit the scene in 2017 after being coined by the founder of Weaveworks, joining the ranks of other ‘Ops’ suffixed words like DevOps, FinOps and DevSecOps. GitOps is on the rise in response to an increased adoption of Kubernetes; when organisations move to Kubernetes there’s an increasing need to effectively scale. Combining the source control tool ‘git’ with how it’s applied to software operations, ‘ops’, the GitOps set of principles is designed to enable development teams to effectively manage Kubernetes clusters and deliver applications with speed and at scale.
In the modern, cloud-native world the vehicle for delivering business value (applications) is Kubernetes, it is well established as the de facto standard. Kubernetes is powerful but also brings with it a lot of complexity. Because of this, organisations are looking to new ways of working such as GitOps.
The GitOps way of working has proven to have a huge positive impact when implemented correctly and under the right set of circumstances. But that’s just it - what are the right and wrong circumstances to use GitOps? As a CTO, it’s crucial to uncover the potential consequences of using GitOps and its overall positive impact and change it could have compared to the investment into re-aligning work practices.
One thing’s for certain here: In order to stay above the water and thrive in an ever-changing environment, you need to embrace change. And change isn't just driven by the technology stack you adopt.
People and processes are just as, if not more, important as the technology that supports and drives them. GitOps is a perfect example of prioritising process because it’s not a set of cool new tools, it’s an entirely different way of working which can plug in seamlessly with product centric teams (‘you build it, you run it’ teams) that are supported by a platform, which is the Nirvana for many organisations.
At first glance, GitOps principles are straightforward to start working with. The focus is around using a version control system (such as Git) to house all of your infrastructure’s code, and uses automation to apply that alongside any changes that are made. Developers love GitOps because it lets them keep workflows closer to their chest. And CTOs love GitOps because it allows developers to reach their maximum potential (and productivity).
At a very base level, these four principles are what make up a successful GitOps workflow. Whichever way your teams spin it, implementing these principles is what’s going to drive the biggest impact.
The principles of GitOps listed above aren’t entirely dissimilar to Infrastructure as Code (IAC) but there are a couple of key differences which set GitOps apart from other ways of working.
GitOps isn’t the first, or the tenth, disruptive way of working to hit the scene. But there’s a few key things to differentiate between the more standard formats you’re probably familiar with.
Infrastructure As Code (IAC) has been around for awhile — a quick Google search will return the usual suspects of Terraform, Ansible, Chef, etc... It could be one of the main reasons a new term was coined, there simply wasn’t enough room for the next evolution of IAC to exist in the same space, which is essentially what we have now with GitOps. And, in fact, Priyanka Sharma, General Manager at CNCF, says that the GitOps workflow concept was effectively created by:
“everyone who successfully did infrastructure-as-code."
GitOps focuses on containers as the deployable artefact. These are then scheduled through an orchestration layer such as Kubernetes, a style of infrastructure as code designed with the cloud native era in mind.
And although GitOps practices work within any software framework, it works particularly well with Kubernetes. GitOps uses merging and pull requests to deploy Kubernetes, using processes that developers are already familiar with to bring the whole workflow closer to them.
DevOps is a term on the tip of the tongue more often than not. It’s become an ingrained part in most development cultures, rather than a set of practices. A key difference is that DevOps isn’t tied to any tool - like GitOps is with Git.
DevSecOps was coined to represent the intersection of, you guessed it, development with security and operational practices with an aim to integrate best-practice security into the software development lifecycle, but balance it out with development speed. Essentially, it’s how DevOps should always be done: with security as a key part. Regardless, it’s a mindset shift which can be used alongside GitOps - with Git as the single source of truth.
GitOps could be a time-saver and to optimise DevOps teams working with Kubernetes, especially when loosely comparing it to other ways of working in this space. But it’s imperative to see how GitOps actually works in real-world practice.
As mentioned before, GitOps is intrinsically connected with the DevOps concept of ‘you build it, you ship it’ product teams. Within these teams, Git is hailed as the single source of truth, as any desired Git tool is used to create pull requests to subsequently trigger deployments of Kubernetes clusters. What happens here is push-based pipelines are replaced with pull-based pipelines to allow developers to perform deployments directly with pull-requests.
This process is supported by an infrastructure that kicks off a series of events in the deployment process once developers perform merges or open up pull requests. The GitOps operator can detect a change when a pull request is opened, which leads to another operator declaring the changes and deploys them to the cluster. The actual infrastructure to implement this varies on your preferred tool stack, but the mechanism is the same.
Today organisations are facing an increasing amount of challenges, applications need to be stable and work at scale. And, without a doubt, GitOps is a contemporary answer to the ever-evolving pursuit of optimised development practices and can be a powerful practice to manage Kubernetes and modern cloud infrastructure.
But GitOps might not fit with every organisation, it really depends on where your business is at and you want to go. Assess your business and create a matrix that uncovers what needs to change. The business decision of whether or not to start using a GitOps approach within your teams or organisation then comes down to what you need to manage and how much you want to manage.
If you can abstract enough complexity and infrastructure layers away from Kubernetes, GitOps could be the answer to unlocking your team's productivity. Or, if not implemented correctly and under the right circumstances, leave your teams with a ton of rogue code to manage.
