CBA builds container-as-a-service platform on AWS, Kubernetes stack
Limited Time Offer!
For Less Than the Cost of a Starbucks Coffee, Access All DevOpsSchool Videos on YouTube Unlimitedly.
Master DevOps, SRE, DevSecOps Skills!
Source:-https://www.itnews.com.au
CBA has provided its first detailed look at a container-as-a-service platform it stood up for development teams, and the guardrails wrapped around it to meet regulatory and security requirements.
Lead engineer Dário Nascimento told AWS re:Invent 2020 that the bank built the platform on an AWS stack and is using infrastructure-as-code practices and tools to manage configurations and compliance.
The bank – an AWS customer since 2012 – was cited in a recent blog by AWS chief evangelist Jeff Barr, though it had been unclear for some time where its focus with the cloud lay.
It is now clear that much effort of late has gone into the container-as-a-service platform and into containerising applications across more than one internal business unit or “department”.
In notes promoting the session, AWS said CBA had “built a platform to run containerised applications in a regulated environment and then replicated it across multiple departments using Amazon EKS, AWS CDK, and GitOps.”
EKS is Amazon’s managed Kubernetes service, while CDK – cloud development kit – offers a framework for companies to manage cloud infrastructure as code.
GitOps, meanwhile, is “an operating model for the delivery and management of cloud native applications on Kubernetes.”
“The core idea of GitOps is having a Git repository that always contains declarative descriptions of the infrastructure currently desired in the production environment and an automated process to make the production environment match the described state in the repository,” Walmart Japan cloud solution architect Bhargav Shah writes in an explainer.
“If you want to deploy a new application or update an existing one, you only need to update the repository – the automated process handles everything else.
“It’s like having cruise control for managing your applications in production.”
CBA’s Nascimento said that the bank’s use of GitOps – and the architecture of the container-as-a-service platform generally – was optimised for service security and resiliency, and to give auditors and financial regulators confidence in the cloud-hosted infrastructure.
In that way, CBA is treading a similar path to that of other banks with cloud ambitions: NAB, for example, has its CAST framework which it used to get the Australian Prudential Regulation Authority’s (APRA’s) blessing.
“We kind of use GitOps and infrastructure-as-code as an immutability firewall,” Nascimento said.
“One of the core principles is that our applications must be declared in code in Git, defining the state we want the system to be, [the] drivers and the operations that we want it to execute, and then Gitops operators such as Kubernetes and [AWS] CloudFormation systems will ensure the services reflects the state you defined that in code.
“That means humans only need read-only access for observability purposes.”
The container-as-a-service platform is also intended in part to make the job of auditors easier by implementing many security and compliance controls automatically, with development teams adding only a few controls of their own for their particular service or application.
“Financial institutions are regulated environments and must perform risk management to be compliant with the expectations of security and regulators,” Nascimento said.
“I consider [security and regulators] like ‘bar raisers’ for processes and mechanisms.
“Risk management is a constant process that assesses what risks exist and then find controls to mitigate those risks. Controls are like requirements, defined by security, by risk, by engineering teams, usually based on standards such as ISO, PCI or industry regulations. These requirements aim to detect, prevent and mitigate something that might happen.
“Auditors will demand evidence proving that controls have been implemented to ensure that the system is actually compliant.”
Nascimento noted that if each internal team composed its own Kubernetes platform, each would then “have to repeat this auditing process and provide evidence that their version of the platform is also secure and compliant.”
“This approach will definitely not scale,” he said.
“So we built a container-as-a-service platform with the … risk assessment to ensure the platform is secure and reliable, and just like with the ‘AWS shared responsibility model’, we implemented controls on behalf of the users to reduce the length of the architecting process.
“Users will only need to implement the few controls where they have to create a new service, and the auditors will absolutely have a more expansive trust base so the auditing process can be much quicker.”
Nascimento said the container-as-a-service platform also helped CBA “scale software development in an innovative, sustainable, reliable and secure manner.”
Aside from aiding auditors, GitOps was also intended to “empower developers to follow best practices so that services are well configured and reliable.”
“Service continuity and reliability is a must in the financial industry so when we designed this container platform, we optimised for service security and resiliency; in other words, for minimising the access permissions and the blast radius,” Nascimento said.
“We converged on running one cluster per AWS account and two accounts per system, a non-prod account and production account.
“A system itself is composed by multiple services within a single business unit.”
The multi-account strategy enabled CBA to effectively segregate systems, such that if one failed, it did so within “a well-defined blast radius” and did not impact other systems.
Nascimento did not talk about which business units run workloads on the container-as-a-service platform, nor the types or numbers of workloads, instead focusing purely on the architecture and guardrails the bank had laid down for the platform.