Hello everyone and welcome to my talk. As I mentioned in my introduction, today I'm going to present Piacere, a research and development project founded by the European Union. And Piacere is all about DevsecOps, all about automating devsecops, all about ensuring that Devsecops is usable in customers'environment. This presentation has been prepared by me and Pablo Schibeck. We are both from seven bullscom and a little bit about ourselves. So in this project especially, we are acting as a research and development center in polish center Badavcheros voyove. We have the status in Poland and in France as well. And I guess this is enough about us. Let's get going with the topic of the presentation. So regarding the devsecops, quick reminder. So in general this conference is all about devsecops. So I'm guessing you know what devsecops is, but a little quote from Gartner's it glossary on what devsecops is. So Gartner claims Devsecops is the integration of security into emerging, agile it and DevOps development as seamlessly and as transparently as possible. And basically as it goes on. Ideally this is done without reducing the agility or speed of developers or requiring them to leave the development toolchain environment. And precisely this is where Piacere aims to fit in. As we know, devsecops is hard in general. So the experience shows that many companies are struggling to add this sec to DevOps. Even if they moved already to DevOps. Some companies are still struggling to move to this more agile, formal DevOps. So that is one part of the equation. Another part is that adding security to DevOps is not as easy as it seemed, at least initially to some. So this is the framework that is going to make it easier for those companies who struggle with adding security to their DevOps pipelines. And a little why do we need SEC in DevOps? Again, based on this conference, I guess I don't have to persuade you too much at least, but a quick slide about that. So security, security. So security is important in general. But then if we consider DevOps and agility that comes from DevOps, when you have your infrastructure all software defined, you have software that powers your infrastructure, that powers your software. Again, you are adding new points to be attacked in those scenarios, and thus you need security for your DevOps as well. Additionally, if you consider the agility, the agility comes with increased frequency of built and deployment processes, and this increases the attack surface. So in general, recent news about the attacks on the delivery chain, on the way that we deploy our infrastructure, the way that we deploy, for example, our containers show how security is important at this stage as well. And another point to mention is that heterogeneity of infrastructure is another risk. So if you consider agility, if you consider the frequency, if you consider the heterogeneity, then the security part is a must, in that if you want your DevOps to be sustainable, to really affect your business in only a positive way, let's say security in DevOps is crucial. So devsecops all the way. And here I introduce piacere. And as I mentioned the introduction, piacere is actually an acronym. So it's this very long sentence being acronymized into piacere. So Pichera is actually programming trustworthy infrastructure as code in a secure framework. So the framework itself is supposed to be secure. The framework is all about the infrastructure as code. So the way we do DevOps normally, and making sure that this infrastructure as code is trustworthy so that it is secure as well. And a quick recap, this is a horizon 2020 project in software developers call our consortium consists of twelve organizations, and those range from academia, business and government. And consortium is led by Technalia and Technalia is from Spain. So the project started a year ago. Now that you're watching this video, it has already been a year since it started. And we at seven Bluescoscom, we are responsible for the integration part. So ensuring that everything works in the end, let's say. And also the part about the Canary sandbox environment, more on that later. And here about the tools of Piacere devsecops. So this is probably already familiar to you, what could be the goals of DevOps and security in DevOps. So first and foremost is obviously to develop, build and deploy applications, because otherwise what's the point of doing this? Then again, as I mentioned, this heterogeneity, so we are moving towards the cloud. If someone hasn't moved toward the cloud, then they are probably going to hybridizing the environment. So doing something on premises, doing something in fog, doing something in edge, and also having those multi cloud deployments when some services are running in a different crowd from the other services, or even load balancing the traffic via those multicloud deployments, similarly maintaining and figuring the infrastructure, because if you want to get your applications on something, then this something is the infrastructure. So the infrastructure is actually the main part of modeling in piacere. And with that goes the optimization of the usage of resources. So the infrastructure resources that are given to our applications are going to be optimized so that the optimal set of resources is being used at all times, as well as given this framework for testing the deployments and testing the infrastructure in general. And the final goal is what usually butchers the security in DevOps, in infrastructure in general, is the concept of snowflakes. So if you don't remember what snowflakes is, I urge you to look it up quickly. But in essence, Snowflake is a server that was specifically crafted for some purpose and it hasn't really gone through some regular procedure. Let's say in a company it has been manually configured, for example, to achieve some level of performance, to deploy some very custom application that is generally not supported inside an enterprise, and then left as it is, perhaps some administrator has already moved on to another company, and then you are left with this snowflake that has been very much cared for at some point in time, but in general the time has forgotten about it. And then you've got this conflict drift and the conflict drift. So anything that you are not expecting, that you are not monitoring, that you don't know that has drifted from the great standards that you have set for yourself, may affect your actual security. So that is some point to consider and the framework is actually disallowing you from doing this. So this is discouraged both in documentation, let's say, as well as in the approach that is kind of forced on you. So moving on to the key features of your chair. So yet again, the integrated security principles in those DevOps operations. So the development and the actual deployment as operations agile approach without losing security level. So that's the key feature, one of the key features, sandboxing guide to test the dynamic properties to be deployed infrastructure. So this created to the cannabis sandbox environment. I'm going to talk about it more soon as well. Another important point, and I want to stress this particular one out as single source of truth. So if you've been exposed to term such as git ops, when you are supposed to control all the config that you have via git repository, this framework is actually designed to work with that. So that you have this single source of truth, you have this git repository when you have all the configs, when you version them, when you ensure that they are managed properly, et cetera. So this access control, accountability of that procedure, this is probably one of the most important points to take, if anything, from this presentation. Basically, if you consider those snowflakes that I have just mentioned, the way to ensure that you don't end up with snowflakes is to have procedures to control access to the actual config that is being deployed. And the best way that we have as a humanity developed so far is the usage of version control systems. And nowadays this is most of the time git knowing that some folks still using subversion. So if you are using subversion then it's fine as well because the general principles are the most important ones. But you know the drill. Another key feature already mentioned as well regarding the multi cloud approach, cloud agnosticism. So that we are not fitting into one offer, for example from Amazon Web services, but we are considering all the other potential cloud providers, obviously the major ones like the Microsoft Asia, like the Google Cloud platform, but also all those platforms, public clouds with running OpenStack. So in general the cloud agnosticism is a key feature of petrare and also important part automatic healing and optimization. So ensuring that the infrastructure that has been defined first of all doesn't drift away from the actual configuration and is healthy at all the times, and also proposing optimizations to the way that the infrastructure scope is defined. And here is how we are going to go about that. So as I mentioned, this is quite a young project. So we are only a year in and this is some architecture that we have designed so far for piacere. First of all, we are going to have some ide for the user where the user is supposed to actually design the infrastructure as code, and the infrastructure as code is actually designed using an intermediary language called Dumml DevOps modeling language, more on that later as well. And as you can see on this diagram in the left upper corner, you have design time. So these are all the parts that are for the design time. So first of all, as I mentioned, eclipse ide, very likely this is going to be the web based ide as this is the most modern one and what most people nowadays expect to be. So the eclipse chair based on Eclipse TIA, and in there you're going to have those modeling tools, the support for the DamL language and also the interface to the other piacere tooling so that it is callable from the id itself. So having the user modeling the doml, then the ICG, the infrastructure code generator is used to generate the IAC that could be actually deployed on the infrastructure as we generally rely on the existing tooling, for example terraform for example, ansible to do the hard job of running the infrastructure as code, let's say. But the modeling language has to be. So the designing the modeling language in the domal has to be converted to that runnable IAC and this is where ICG comes in. Also, both the DOM model as well as the generated IAC go into this verification tool. So the verification tool is a general verification tool as well as security verification tool. This is where the emphasis is on the static testing of the generated IAC. More on that later. As well as I mentioned already, some git repository tooling. So this is kind of agnostic what that tooling is. It could be, for example GitLab, it could be something else, something like Garrett and Gitia for example, and creating those pull requests or merge requests, whatever, with the Domal and IAC that have been verified using the static verification step. This all goes into the runtime control that ensures that the processes relevant to the deployment actually start and ensure that the flow completes for that particular deployment. The IAC executor manager, the IEM is what actually calls the ansible, the terraform, whatever else to execute the IAC that was presented to it. Information about what is being deployed, what has been deployed is stored in the infrastructural elements catalog. And this is used for two purposes, as you can see. Well, even free purposes. But two purposes have already been called out, let's say. So the infrastructure elements catalog is used as database for querying from the id. So what are the possible choices for you as the user? What cloud be deployed? And then again, the information about what has been deployed is also saved in this catalog. So moving on, the flow then moves on to the infrastructure advisor. The infrastructure advisor sets up monitoring and analytics. The self healing, the optimization part of piacere is all in the infrastructure advisor, and the infrastructure advisor is also connected to the infrastructure elements catalog. It's actually the third usage of the infrastructure elements catalog that I've mentioned in that all the data, all the performance data, all the information about the state is stored in the elements catalog for easy querying. And this easy querying is for the optimizer part to be able to decide on the optimal strategy to propose. And all the others are concerned with the resource provider. And there are two kinds of resource providers from the PHRA perspective, the production resource providers. So those that actually exist for some production purpose, even if you're using it for testing. This is something that is generally considered to be production like. But there is also this tooling Canary sandbox environment tooling that is about provisioning specific kinds of resource providers, the canary sandbox resource providers, and those are especially to be used for development and testing of the generated infrastructure as code. More on that later as well. So in general, that's the diagram that's showing how the workflow of your cherry could be because it's not there yet as this is only a year in. So we are presenting how we are thinking about it, but not how it works already. But this is the general concept and the general view of that. So we are proposing something else. We are proposing something else again. And I bet some of you already know this image from XKCD about how standards proliferate and well, we have to really show why we are doing this instead of just saying that we have to do this because so, and our main point is that it hasn't been done yet. So many companies are struggling, as I mentioned already, with deciding on the approach to security in DevOps. There's really no complete, let's say standard for devsecops only. Kind of like parts of what piacere is going to propose are kind of standardized, say. But other than that, the devsecops is just wide west nowadays. Still, this is unfortunate and we are working to change that, to change this perspective. So first and foremost, this is to be simple and easy way to use devsecops approach so that you don't have to think too much, so that you don't have to worry about whether you are doing the devsecops right or not. We are proposing this as end to end solution for you. Unified way to build and deploy into the multi cloud environments already mentioned as well. Not relying on a single target platform but supporting all the environments, the ones at the bottom are the ones that we are thinking about the most at the time of this project. But in general, the project is going to be extensible. So if you find a need to use another resource provider then this is easy to actually add. So thinking about the other providers that aren't using OpenStack but are still public resource providers, cloud resource providers, then this is easy to add later support for multiple IaC languages so that you are not bound to a single IAC language. So again, the extensibility point comes in here. As I mentioned, the ones that we have considered so far, we have considered so far include terraform and ansible. But this could change as well automatic deployment to different cloud providers so that you don't have to worry about the details, how to contact the different cloud providers. This is already abstracted away from you. For you, automatic optimization of cloud resources. This is again important that you are not left alone with the optimization stage. If you require the optimization. The way to do it securely is also to be built in in deputy framework. And finally the embracement of Githubs with a single source of truth and streamlined access control. As I mentioned already, these are the selling points. As for why to go pitcher with your devsecops and the key elements, I've already kind of mentioned them, but a quick recap, those will be now described in much more detail on the different slides that are coming. So the first one is devsecops modeling language. So actually this is only for the D ops or DevOps modeling language. But in general, since we are dealing with security as well, this is Devsecops modeling language. Then you've got the verification tool. As I mentioned, this is both for the security as well as the formal verification of the DOM and the IAC, the central DOM and IAC repositories and running control. So this is actually the git repository I was mentioning and the random controller that is providing the general workflow of the petrol framework. Then we've got the IAC, the IAC executor manager that actually executes the IAC, the kind of sandbox environment tooling that is kind of a helper service in here, the infrastructure elements catalog that contains all the different information still to be defined as well. So let's wait a couple of slides more to learn more details about that and the infrastructure advisor, which is about the random monitoring. So for the performance and security as well as this infrastructure optimization platform, and also the bits that are not shown here will be shown later for the self healing and self learning of the data. And all this is integrated together in the Piazza framework. So as I mentioned, this is an end to end solution for devsecops. And now moving on to this first component mentioned. So the Domal, the devsecops modeling language. So this is where we are going, cloud agnostic. And the way that it's phrased in the slide, the cloud agnostic able language, is because we are allowing the user to actually ignore this fact. If the user is willing to use a very specific feature of a certain cloud provider, and that is not available anywhere else, or that needs special configuration for that particular provider, then the user is welcome to do that. This is obviously blocking the multicloud approach for that particular part of the IAC, but otherwise there could be more generality in other parts. So to achieve that we offer multiple layers of modeling and presentation. So we are showing this abstract modeling when you have it, environment agnostic. So for example, this cloud agnostic and complete level where you have environment dependent data. Application modeling is minimal. In here we are focusing on the modeling of the infrastructure. So digital parts like the complete, what is to be deployed, how it's connected, what are the security relevant aspects that's in there. But other than that, the very detailed like it could be application modeling is not part of the dummy. The target act generation is possible and it's into multiple languages, as I mentioned, terraform ansible, the basic ones that we are offering at the beginning that we are thinking about at the moment. And the modeling toolbox is available in the eclipse id and I mean the web actually the eclipse share id based on eclipse there. Okay, so that's for the demo, now for the verification tool. So as already mentioned, static analysis of the domino and the generated IAC to verify the correctness according to select criteria. So it's also configurable to ignore certain parts if the user wishes to ignore them. But in general this is offering a wide range of criteria to analyze the domain IAC for those formal correctness as well as the security aspects of that. And this is to ensure that the IAC and the companies that are used are free of known vulnerabilities and that they follow best security practices. So this is what can be achieved at the static analysis level and this is the tooling that does specifically that. And this is very much related to the code generation. So this again for the time being focuses on ansible and terraform and is made to be extensible to support other languages for this single domain IAC repositories and runtime controller. Again think repositories like the git repositories or subversion repositories if that's your thing. But in general this is about the single four operations. So pushing to the repository, getting your deployment updated via that, probably with some procedure like using the merge request, the pull requests to actually confirm that the OPS person is willing to proceed with this change. This allows for the single source of truth approach where everything infrastructure, it's all in one place, it's defined there, it can be compared against the state. This is also the way that for example kubernetes pursues this, where you define the desired state and then you can compare against this desired state. So this movement was inspired by this, by this approach in kubernetes, again simplified and streamlined access control. So control access via repository permissions and any procedures that your repository tooling allows you to do, to verify, to control, to ensure that the right people are stamping the change to happen in your infrastructure. That's all available to you with that approach. As for the random control, as I mentioned, this is for the workflow of the general framework and this is based on BPMN. So the business process model annotation and this allows for quite an extensible vernacular, this mostly not to be modified by the end users of piacere, but it's there, it's flexible and it allows for further customization if such it arises. And now on to the IAC executor manager. IAC executor manager is all about the execution of IAC, so it has to understand the tooling that deploys the IAC. So for example the Ansible playbook command, the terraform comments and outputs of those comments, and the state that they save, the logs that they produce. This is all in the IAC executor manager which understands those. Again, I'll be repeating myself thinking in this first release about Ansible and terraform, but yet again being extensible about that. What's more, it actually is to understand the deployed infrastructure. So to be able to save this information to the infrastructure admins catalog that something has been deployed. The infrastructure as code executor manager is to understand the deployed infrastructure, understand what has been deployed and where, what the parameters are, et cetera, that are relevant for storing in that catalog, as well as support for reconfiguration scanning is also in the IM. So reapplying the ansible pegboards or the terraform terraform configs and scaling, applying the scaling procedure via the IM is also in here. This is also what supported both the actual resource providers, the production resource providers, as well as the canary environment resource providers. So it's like the universal solution for using IAC infrastructure and secure use of credentials to the target environments. This is also the part that actually integrates with your, for example Hashikov's vault where you store your credentials. And those are obtained by the aims itself, not the other components. As for the Canary sandbox environment tooling in here, we are proposing two tools. One is the provisioner. So the provisioner is about the deployment of select environments in an opinionated way. So as most of you may know, especially OpenStack. But kubernetes as well could be quite daunting for the deployment part. And we are proposing an opinionated way that is deploying the minimal set, let's say, of those complete that are required to run applications models specifically for OpenStack and Kubernetes. So you have this like one click, one button way to deploy your OpenStack cloud, your Kubernetes cloud, so that it can be used by the rest of the framework. So this is mostly for the testing and development aspect of the framework. And the other tooling that we are working on and we are proposing in Piacere is the mock cloud. And the mock cloud is about the mocked APIs of selected cloud providers. So like for example, when you have Amazon and you interact with Amazon Web services, you might actually be interested in checking if your infrastructure as code behaves a certain way without actually calling the AWS. And there has been some work in that regard in general public. But this is what we are going to elaborate more on in this project as part of the smoker and in general the Kanai sandbox environment. As I mentioned, this is for testing of the dynamic aspects of the deployment. So like the verification tool lives at the static stage at the design time, but sometimes static analyzes is not enough. Some bits could be omitted in that some could be not observable. And dynamic testing is always closer to the actual behavior that is going to be observed in production and for the infrastructure elements catalog. So like I mentioned, this is storing all kinds of information. We are calling this the central storage of local phrase knowledge local because it's relevant to the deployment of the user. So it stores both the offers, but it also stores the historic data. The information that was obtained about the performance metrics, security metrics of the actual deployments, and the details on actual deployments as well are all in the infrastructure elements catalog. And the infrastructure elements catalog can be used to answer the questions as to what providers are available, what the offers are so like for the optimization part, if you are optimizing for the cost, the way that the PSA framework knows what the costs are, what the available options are ahead. This is where infrastructure elements catalog comes in. As I mentioned already. Yes, it stores the history characteristics of the offers. So if you are optimizing both against the cost, optimizing for the cost as well as for the performance characteristics, because you are interested both in ensuring that your users get the right levels of SLA and you are optimizing for the cost because you don't want to overpay for the same performance, this is also useful information for the optimized and the optimized. And the monitoring comes from the infrastructure advisor, and the infrastructure advisor has those two main parts. The first part is the random monitoring for performance and security, and the other part is the actual optimization platform. So the goal of the monitoring is to collect those metrics and events related to performance and security, actually to self learn and self heal from that. So discovering those small discrepancies and healing them right away, and also self learning from the data to discover that certain issues are going to repeat soon. Like for example from the data, the last time that you've seen those spikes, you soon needed another instance to be provisioned. And this is especially what the self learning is about. But similarly, the self learning is about the security. So discovering patterns in how the security could be violated, what aspects of the security are relevant to that, is also in that self learning and the infrastructure side. So like you probably recognize. So when you want to monitor something, you need to somehow access the systems. So this is an approach with agents. So the agents are actually deployed during the IEM run. So the IEM gets those additional, let's say for example ansible playbooks or otherwise, the infrastructure scope to deploy the actual agents to be configured with the infrastructure advisor so that the metrics can be collected from there. The IOP, as I've mentioned, the platform for the optimization, it actually computes the optimal solutions based on those collected metrics. So it collaborates with the infrastructure elements catalog and the trade offs that are to be optimized of the cost, performance, availability, et cetera, style. So those aspects, and this is using multi objective optimization based on machine learning. And that's it for the optimization side. I guess this was also the last slide. Yes, I was right. Okay, so that's it from me for this presentation about piacere. Thank you very much for staying with me, for listening to me and let's stay in touch. If you want to reach out to us, this is our website. If you want to reach out to us for seven boost.com, our company name is our domain, so you can find us there. Thank you very much again and see you.