 Okay, so hopefully this is working. Hi everyone, I'm Freddie. So I am a engineer at Deutsche Bank and I'm going to talk you through a project that we've been working on with Finos for about 18 months now called the cloud service certification project. So I'll quickly introduce myself. So I work in PNL technology at Deutsche. I've been with the bank for about two years and I've been working on this project for about 18 months, pretty much since we first got involved with it. So I'm going to talk you through cloud service certification. The idea behind the cloud service certification project is that all major banks pretty much are trying to adopt public cloud one way or another. And the way they're doing that is by going through each service and working out what risks they need to calculate and what their settings need to say on their cloud services. So if you're trying to create a, if you're trying to put bank data in a Postgres database on the cloud, for example, you would need to have certain settings enabled like maybe encryption at rest or encryption in transit. The ramifications of that is that as a bank, if you're trying to adopt public cloud developers in banks are generally used to only being able to create things that are compliant and secure. So if I'm a developer at the bank and I don't go into Deutsche Bank's policy documents and make sure that I can do what I'm about to do before I deploy to OpenShift internally, for example. I just do it. And the reason I can do that is because I know that anything I'm able to do within Deutsche Bank's network is compliant and secure and complies with the bank's risk appetite. That is often taken for granted by people who work in banks, but there's a huge amount of work that goes into enabling that to be the case and making it easy for developers to focus on solving their problems rather than constantly thinking about, am I missing a regulation here and there? And of course, the reality is that even if banks did require developers to go and look at those policies, that wouldn't be a workable way forward because there's just too much to think about. Deutsche are operating in around 80 countries and we've got nearly 100,000 staff and some banks are bigger. And so that's not really workable to say to a developer every time you want to do anything, you have to go and check those policies. So we've got to maintain that ability for anything that happens internally is compliant and secure by nature. So how do we maintain that while we're adopting public cloud? That's what the cloud service certification project aims to achieve. So a quick introduction to the project. The collaborators to the cloud service certification project are mainly have mainly been Deutsche and JP Morgan up until a few months ago really. Finos has been leading the project and Finos, as many of you will know is a Linux Foundation member joining this year. And so the Finos team have kind of guided Deutsche and JPM to lead this project. We've had a lot more collaborators getting involved over the last, well during 2020 really. We've now got Morgan Stanley. We've had UBS involvement. We've had a lot of help from Red Hat and then the cloud providers themselves, Microsoft and Google and various other companies. We've had CS, we've had City Hub and consulting companies that are helping us to kind of work out the most efficient way of collaborating and solve some of the technical challenges with us. So that's the collaborators and there's sort of banks are in and out on this project and we're really pushing this because we've kind of seen that this could be a really, really valuable asset for us. So the project purpose, the mission of the cloud service certification working group is to accelerate the development, deployment and adoption of a common set of controls and tests for cloud services. You can see that on the screen. And so that the long and the short of that is that we want adoption of public cloud for banks to be very easy. And we've recognized that there's no intellectual property for banks in the ability to adopt public cloud right so you know our IP does not sit in our ability to adopt public cloud all banks are trying to achieve the same thing. A lot of banks are trying to comply with the same regulations so rather than reinventing the wheel and kind of over and over again all of us coming to the same conclusions about the same services. We were just collaborating and doing that work centrally. So why is this why is this necessary. Well the majority of cloud security instance are due to human error. So you can read the quote on the screen and capital one is a really good example of this. Apologies if anyone from capital ones on the call, but last year capital one had a breach in public cloud. That data in the public cloud in an AWS. I think it was an easy to bucket and that data was compromised that data, however, was not hacked in the in the sort of brute force sense of the word so it was a it was a misconfigured container. And so, where does the blame sit so this was one of the first, the first problems of its kind and this was a really interesting case study for those of us that work in financial services, because what it says is. Okay so it was made only as his fault because the container did exactly what it was supposed to do. Was it capital ones fault well. But that that it was it was a case of not having. I guess tested the different settings in AWS and of course that that those switches are not owned by capital one themselves and you know these these cloud services are a complex and there's a lot of. There's a lot of switches there's a lot of settings that you can apply to all the different services, particularly when you're working across different cloud providers Google, Azure, AWS, Ali cloud, etc IBM Oracle. And the result of that was the US bank shares slid nearly 6%. That's what we're all trying to avoid really. So from the bank's point of view, what this project provides is much stronger controls proof of compliance so we will be able to prove to regulators to audit and internally that what we're running in the public cloud is because we'll have tests that show us that genuine multi cloud so a lot of banks are talking about multi cloud. That's kind of not a reality for a lot of banks it's sort of one or the other because of the overhead of adopting an individual set of services you know if you if you decide as a bank to adopt. GCP for example, then you have to train your people in how GCP works. You have to know what is available in GCP and you have to make those risk appetite decisions about whether what your requirements are for the containers that you're you're spinning up in GCP. This project will also provide very fast switching between cloud providers and that can be beneficial where you know banks want to diversify across providers rather than having all their eggs in one basket as it were. And it also provides the engineering culture, which is a huge challenge for banks I think trying to build, you know huge numbers of technologists and trying to operate like in that in that kind of famous tech startup culture that the public cloud providers and you know big tech firms do so well. And you know working really closely with those companies on this project provides a huge engineering culture benefit to the banks as well. From the tech contributors point of view, it's access to the financial services industry, which is you know one of the oldest and most powerful industries in the world, and an incredibly difficult industry to get into and understand as an outsider. And so you know my next point or more in depth understanding the cloud providers particularly are really keen to understand the challenges faced by financial services providers because so many of their customers just don't have those kind of challenges, particularly when you're a bank operating, you know globally across regulatory jurisdictions. And it also gives them influence over the public cloud choice so you know working with us on these projects allows the public cloud providers to show the power of their platforms and and what's what's available what they can offer us. So how exactly does this work. So for each service, we will go through this workflow that you can see on screen. So it will pick a service like postgres for example. Microsoft Azure has a has a postgres database. So first we'll we'll build a policy document. We call that a service approval accelerator, and that is defining the parameters of our risk appetite for that service so that's talking about what is compulsory, what is optional, and, and how should those constraints look on public cloud so what should we you know for a database for example, do we need encryption at rest do we need encryption in transit. What which IP address ranges can we expose. And what are the options there as well so the service approval accelerator not only says, okay all banks have to comply with this or or we don't need to care about these but it actually also says. So there's some options here depending on what kind of data you're putting in the cloud and from a financial services point of view that's really valuable because, of course, the cloud providers themselves could tell us. It could tell us what options there are but they're not going to be able to give us the kind of insight from a financial services point of view as to okay. It could be required by x regulator or there might be a knock on effect of a certain of a certain setting. So once we've defined that service approval accelerator that that policy document, we then move on to creating BDD test scenarios so we want, we really want this to be easily accessible easily readable and as you developers out there will know, you know gherkin files cases are really, really structured easy to understand way of writing tests at the top level, and the really good way of right of mapping tests onto requirements we've defined those requirements in the policy document we're now mapping them on to those BDD test scenarios. So we've written our BDD test scenarios are gherkin feature files. We then map that further onto policies code. And that can be terraform. We're currently having a discussion over terraform versus a couple of other providers and that that policy is code will allow us to spin up actually spin up the containers themselves using the compliance as code that that's in our repository. So if you're a bank and you're wanting to create a postgres database and you want to comply with certain settings you can download these terraform scripts and spin it up and you know that they're thoroughly tested and you've got the BDD scenarios and you've got the policy document to explain exactly what regulations you're you're complying with. And finally, you've got your test fixtures. So those are kind of back testing on the BDD and on your terraform scripts to ensure that once you created your once you created your containers, those are indeed doing what they're supposed to do. And, you know, you can kind of test that the that the behavior is as it's expected. So let's go and look at some code. So I'll flip over to our GitHub repository. This is just illustrating at the moment we've got Google Kubernetes engine is a work in progress postgres honors year. We've just contributed their service approval accelerated for that and Amazon Redshift was contributed by JP Morgan previously. So this is the cloud service certification main project. It's open anyone can join it and if developers would like to get involved then then please do drop me a message afterwards and let me know. I'll show you the service approval accelerator for postgres because I think that's a really good place to start. So the format is a markdown file we want all of it to stay in this GitHub so that we've got a single single place to access the whole project and so that as I say it's as accessible as possible it's as easy to understand and really lots of different financial services institutions can access this information. So if I flick through a couple of these identity and access management, for example, if we look at authorization we're saying that it's recommended to only assign active directory as your active directory groups within postgres not create individual users within postgres itself. So what we're saying is that you'd have an active directory as your active directory instance honors year and those roles are used to define the access to your database. So that's an example of a specific, you know, we're saying this is the way we think you're going to have best control over your authorization to your postgres database. So if I flip down to another one, we've got encryption at rest. So we want encryption at rest it's required for data governance and compliance efforts. We've cited a few government and industry regulations HIPAA PCI Fed ramp laying out specific safeguards regarding data protection and encryption requirements. And we're also saying that we want that data encryption to be using customer managed keys. So, as your allows you to bring your own key be okay for data protection at rest, and that allows you to actually hold the keys yourself rather than having the keys stored in as your key store. So you can flick through this service approval accelerator and you can see plenty of, there's lots of examples so IP firewall rules run to network security now. And we're saying that if you want to create your network honors year, then we've got some recommendations for how you could build that, creating proxies to allow you to access your company network from Azure. And obviously not opening your public IP addresses to the outside world so you only want to be able to access that from within your company network. So that's the service approval accelerator. I'll show you an example quick example of a bit of code so we've got some we've got some pull requests open here. And Kubernetes we have. We find the right one. And Terraform scripts being contributed as well. This is really slow. Apologies. Okay, here we go. So we've got some Kubernetes scripts here. And here's the service approval accelerator for our Google Kubernetes engine. That's our markdown file and then we go in here and you can see, we've got some Terraform scripts. So if I open up the main Terraform script. We're creating Google compute network compute firewall right the way down to the Kubernetes cluster here. And that's using the settings that we've recommended in our server service approval accelerator. So that's how we recommend we're going to we're going to go forward we're really trying to start with the code. And so we're going from the ground up and we're this project is saying let's just pick a service. Many of the companies involved in this project can pick a service and go ahead and, you know, start start building defining a service approval accelerator that's then discussed by the group. And then that that information is contributed to the repository via pull requests. So for Deutsche that's linked up to our internal bit bucket repository and we can push that over a proxy to the outside world for some companies it's not that difficult. Yeah, if you'd like to get involved, then please do let me know. We really welcome individuals and organizations to get involved in this project. Whether you're wanting to contribute Terraform whether you're more on the cloud side or indeed just wanting to get involved in the discussions around the risk appetites and service approval accelerators. That would be really valuable to us. So I'm going to open it up for questions and thank you very much for listening. I hope you have a really good open source strategy for them. Cool. So I think I'm live now. So if anyone wants to ask any questions, please do. I think you, if you type them into the chat, then I'll read them out and answer them live. I'll stick around for the slot which is another 10 minutes. So yeah, please do ask any questions. Have we had the chance to take any of the constitutions back into DB yet. That's a great question by James. James is the champion of the project is one of the few people that's been on it for longer than I have. Yeah, that's a great question. So the ultimate goal of this project right is that we have the scripts, these tests, the service approval accelerators, and we have that covering, you know, a good proportion of the services on predominantly the three main cloud providers, Google Cloud, AWS and Microsoft Azure. And we want to have that catalog of artifacts that banks can re consume. So Deutsche Bank, if you've been following the cloud news has just given a really good example of how this project could be valuable. So Deutsche has signed a letter of intent with Google to work on a 10 year strategic partnership. And I don't have many details, but I'm not really able to talk about it anyway so I won't. But previously, I can say that we were looking at Azure as a solution. And because of our strategic partnership, we're now moving to GCP as part of the wider program. So we're really demonstrating a great use case for this project because if this project was in a more advanced stage, then we would have a catalog of artifacts that we could use to re consume on GCP. So for example, we've done all this work on Azure on working out the settings required for postgres container or for Azure Kubernetes as your Kubernetes service. And we want to move that on to GCP SQL database or Google Kubernetes engine. And we will have the mapping in the cloud service certification project, which has been tested by another bank using Google cloud, using Google Kubernetes engine in GCP. And we could just re consume that. And there's no, there's no IP issue there. So the point I was making in the presentation is that there's no problem with the banks sharing this information because it's not intellectual property. It's just a case of how quickly can we get through our road maps to public cloud? So we've got another question. Has there been any consideration as to how these service accelerators can be tested once people merge in new templates? So thank you for the question, Adam. And we at the moment the process is we have a very open group of individuals on the cloud service certification call and pull requests are reviewed by the wider audience. Often we break out and work with specific organizations together. So some of the big banks, Deutsche and JPMorgan mainly have done some work together reviewing PRs. The service approval accelerators and the artifacts generally are contributed from one organization which has developed it, and that is pushed into the repository. And then once it's, once it's available and the PR is raised, then the group can look at how we can merge that and whether there's any feedback we'd like to give. And that might be valuable feedback that the contributing organization can re consume as well, right? Once people merge in new templates, we will try them. And, you know, so I'll, if I come up with a hypothetical example where there is a Google Kubernetes engine service approval accelerator in our repository already and Deutsche Bank are looking as part of our new deal to move to use GKE. We would re consume the service approval accelerator on GKE. We'd obviously review it internally, but all the headway is done. And we know that, you know, BankX are here in global banking. And we know that they, that the regulators are happy with them using GKE, using the parameters that they've defined in the service approval accelerator. And the regulators are happy and their internal security and compliance are happy. So we're pretty sure that that service approval accelerator is going to be something close to what we want to use as well. So we re consume the GKE service approval accelerator, we have a look at it. There might be some organizationally specific changes we want to make. We might operate in regions that have a specific legislation that the other bank might not have to worry about. So obviously we'll do an internal review, but it's huge to public cloud. And the other point in this is it's solving the problem whereby banks have to go through and analyze the risk down to the lowest detail and go through each service because we have this document already. And we can take this to our internal security and compliance teams and say, this is used by another bank. Is there anything else that we have to think about? Is there anything else that you would like to change as part of our risk appetite? But actually, that's a huge start. And, you know, that could save months, if not years of work on some of the more complex services to accelerate that adoption roadmap. I hope I've answered that. Please do follow up if you'd like to ask anything else on that. James, are you looking for more banks and tech companies to join cloud service certification? Well, absolutely. I mean, you know, if people are members of organizations that would be interested in joining the partnership, we have consultancies, we have banks, we have technology companies, big and small that have joined the project and cloud vendors. And we'd absolutely love contributors equally. We have individuals who contribute as well. So if any of you are here, not part of an organization or, you know, in between organizations or would like to contribute in a personal capacity, that would be that would be hugely welcomed and you're really welcome to join the call. I suppose the way to go about doing that would be through GitHub. James, you might be able to add a better, better pointer than that. But yeah, there's that you're absolutely welcome to join the call and please do contribute. Yeah, there you go. So James has just posted in the chat. For those of you that aren't following it to GitHub link to that's our GitHub repository under the finance organization. And within here, you're really welcome to post and say that you'd like to be involved. Please do contribute anything you can, and we'll link you into the bi-weekly project call where you can be introduced to the rest of the team and get involved. So yeah, you're really welcome to do that. Please do. Okay, we've got two minutes left. Anything else? There we go. We're in, we're in a meeting next Thursday and the agenda will be added to the issue soon. So watch that repository. Follow it with your GitHub account and you'll find an issue will come up by James on GitHub. And that will be our agenda for the next cloud service certification meeting and you're really welcome to join it. With regards to where we are, I can give it, I can give a quick update. So, Deutsche Bank are currently looking at contributing the rest of the work we did on Azure before we made the move to GCP. And then there is a PR for GCP for Google Kubernetes engine rather, which I think has just been approved. So Google Kubernetes engine is now in the repository, if not just before being part of the repository. We tend to try and merge the PRs on the project call because that's exciting and we can all approve it. We have the lead maintainer is a member of Deutsche Bank. And he's, you know, done a huge amount of our work on Azure and Google Cloud. We've got quite a lot of work in the catalog at the moment that was originally contributed by JP Morgan on AWS, but I'm not aware that there is a contributor to the AWS work at the moment so if anyone would like to pick that up then please do. And Google is getting a lot of interest partly because Deutsche are interested in it and partly because we've got other contributors that are keen to get involved in that too. And then there's some Azure work in there which really needs fleshing out so a lot of the time we kind of contribute the service approval accelerators first and then flesh out the code, the terraform, the test, etc. Yeah, so it would be really good to get those fleshed out. I think we're out of time so I'm going to wrap up and thank you very much for joining everybody. I hope you enjoyed the talk and please do get involved. We're really keen for contributors. Thank you.