Cloud Native Computing Foundation Crossplane Community Day EU 2021, 14 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Deja Vu: Let's think about security again! - Shripad Nadgowda & Paolo Dettori, IBM

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Deja Vu: Let's think about security again! - Shripad Nadgowda & Paolo Dettori, IBM

While Crossplane is emerging as the new CNCF project for provisioning and managing cloud infrastructure directly from Kubernetes, according to the National Security Agency (NSA), misconfiguration is still the #1 cloud vulnerability. So as we move the control plane for managing infrastructure to Kubernetes through Crossplane, we need to revisit and re-evaluate security and compliance implications. In this talk, we will review on-going security transformations for cloud-native solutions in the form of DevSecOps, Zero Trust and discuss their potential applicability to Crossplane. At the same time, it is equally critical to identify early if there any any gaps, need for new tools and techniques for developers and security experts and call for common best practices or standards across users and providers.

A

Hello, everyone: we are really excited to be part of the proceedings and welcome to our session deja vu. Let's think about security again, my name is sripad naragoda, I'm a senior software engineer at ibm research.

A

My current research focus is on driving the innovations around devsecops, I'm the chief architect of code risk analyzer, the devsic of solution. We delivered to ibm cloud last year and I'm very happy to have joined with paolo.

B

Hi, my name is paolo de tori, I'm a senior technical staff member at ibm research in jordanites new york. My current research interest is in cloud technology containers and containers. Orchestration.

B

I've been working for the past few years on several projects related to kubernetes technologies such as the iks ibm kubernetes service and the ibm mcm debian multi-cloud manager for kubernetes.

B

In the past few months, I've been working with the crossplane community and currently a maintainer for the crossplane provider for ibm cloud.

A

Thanks paolo, so we are, we are seeing a lot of momentum lot of interest across community and across industry in embracing this cross plane right. So we believe it's time for an intervention right. We need to take a step back. We need to see what are the security implications of this.

A

So if we see we, we have seen that misconfiguration is still a number one cloud vulnerability according to the national security agency, and there is a high cost associated with such misconfigurations and it is growing right. We listed the survey which shows that the cost can grow in trillion dollars.

A

More recently, gartner has published a report where they are estimating, but that by 2025 99 of the cloud security failures are going to be responsibility of customers rather than the service provider. We'll put these numbers in perspective when we uh discuss the role of developers and importance of dev secours in the cross plane.

A

Now, let's revisit the the security landscape from the vantage point of four different actors. Now, first, we have a cloud provider, the cloud provider. They are focused on uh improving the experience for the cloud users right. There is a tremendous momentum in onboarding new services on the cloud across aws azure ibm. There are more than 150 products and services.

A

We looked at some of the config. This service configuration exposed to the user based on their respective data from module inputs and variables, and these input parameters input the configuration parameters they can grow and in basically 2030s or even 60s right- and this is very easy for users or developers to make mistake when you have so many uh inputs to care about again, there are different modalities.

A

The cloud provider enables for accessing and changing configurations that includes user interface, cli apis and some programming construct build on top like terraform and cross play right. So it adds a new layer of complexity, because now we need to secure these additional layers and make sure that they are secure.

A

Now, let's uh think about the security director right. So as a security director, he needs a visibility and awareness across the security standards. He need to evaluate the portion of his cloud infrastructures, his cloud workloads and now there are some industry standards like nist, kubernetes, cis docker cis.

A

They cover uh various security controls across workload across kubernetes, core services and across cloud services, but even the sheer numbers. If you look into the numbers, they are huge.

A

So we need automation and there are some emerging standards like oscar that provides this control related informations from the secret standards into a machine level format, so it can be consumed and auto easily automated.

A

There are some enterprise solutions available like aws security hub or ibm security and compliance center, that power the central management of the compliance across organizations and regularly guidelines.

A

Now, let's look at the developer, because developer is the one person who is programming the cloud now if we revisit our days with the open stack. I remember. Writing official custom share script to provision virtual machines to configure network.

A

We are evolved from that now we have standard programming construct, like terraform ansible cross plane, to enable this to standardize this cloud programming model, even the devops. It has ensured that we have consistency across build test and deploy practices across industry across communities and now the emerging practices of devsecops, which is essentially putting developer in the center of the security practices.

A

We don't we don't expect developers to be a security expert and we want to keep it that way and but we want to enable developers to identify the problems in a security problem early in its development process, and so we want to automate these security checks and embed them into the existing development practices. We don't want to invent new development practices, new tools so for developers to learn, but whatever their existing practices are, we need to strengthen them with the security functions.

A

Also, we need to translate this complex security measures that developers hardly understand and provide them actionable recommendations that you don't care about the configuration the cm6 control in nist, but if you just change this variable name or just add this change the value of this firewall from on to off that's the kind of feedback we want developer to give now as a community right again putting that gartner number in perspective.

A

That 99 of uh the faults are going to be blamed to the developer. We need to empower developer the right set of tools we need to. uh We need to educate developers on the importance of the devsec of practices and that's how, as community, we can help and grow.

A

Now, let's revisit uh what are the current devastation practices across uh infrastructure as well as application code? Now, if you look into uh the git repositories, all the artifacts that are present in the git repository, we can broadly classify them into four different categories. We have some artifacts application artifacts like build artifacts, which includes your docker file. Our package, manifest that that says how your application is going to get built. We have deployment artifacts like all deployment, journals and chat that dictate how your application is going to be deployed.

A

Then, finally, configuration artifact, the config maps or network policies, and our infrastructure uh has a core artifact, like your terraform cross plan or ansible, uh and we have existing uh division of solutions that are embedded into this network. So whenever a developer makes any change, this security cr pipelines trigger it, access this source artifact. It performs various checks like on the bill. Artifact, we determine all the dependencies uh all the open source packages we determined there are the vulnerabilities.

A

What are the licenses that they are using? What are the risk of using those uh vulnerabilities uh on the deployment artifact? We analyze? uh If there are any misconfigurations uh like you, haven't, set some resource limits or you're running as a privilege when it is not required. We also measure the risk of such misconfigurations.

A

uh We check the security the configuration artifact to see if there are any application, miss configurations like if I'm deploying some applications. I have a set uh the right configurations for it am I using the right protocol, I'm using the right certificates and finally, the infrastructure artifact, like our data form or crossplay. We can evaluate them and identify any misconfigurations of security holes early in the development, while we are actually before even we're using it for provisioning and then once we have this app pipeline, our artifacts pass through the cia pipeline.

A

We diverge right. We have a separate cd pipeline for infrastructures like admin schematics that takes our infrastructure as a code artifact and provisions associated resources on the cloud and then for the application. We typically produce some intermediary artifacts, like our images in the registry, and then we use cd pipelines like argo, cd or tecton and deploy our applications on the cluster.

A

We typically have the second layer of protections in the form of admission, controller or gatekeeper where we perform some enforcement checks like it is basically second layer of protection, and once our application is deployed, our cloud services infrastructure is provisioned. We have separate monitors, we have continuous monitors to see if the new security issues get stopped.

A

If someone gets malicious activities happen on the cloud or on the workload, and all these uh signals from our continuous monitor gets fed into a centrally managed compliance dashboard where a security director can easily evaluate and uh see the portion of the the overall security structure of its infrastructure.

A

Now we will see how the cross plane is affecting this. Existing dlc cost workflow.

B

Power, thank you shilpat. So, first of all, the first observation is that we cross plane application infrastructure can share the same kubernetes resource model, the same krm so that the basically allowed to now use the same infrastructure, the same tool chain for uh basically doing the pipeline for uh both application infrastructure deployments.

B

So the devsecops pipeline for apps infrastructure now is the same. We can use the same tools because now I don't need to introduce different tools. For example, if I'm doing a deployment with terraform, I have to use the terraform cli, but here I can just use the existing kubectl cli for doing deployment of application and infrastructure.

B

In addition, uh we have now the possibility to have a single pane of glass, where we provide clear feedback to developers about potential issues on the deployment of application uh on the configuration and vulnerabilities, as well as the infrastructure configuration, and so we can say that crossplane is certainly simplifying the model.

B

If we go to the next chart, we see how the pipeline that sripad was illustrating earlier on, where we add two separate pipeline, one for infrastructure, a one for application now can be uh basically merged into one single pipeline because I'm sharing the same tool chain. So uh in this case, I don't need to have a separate, for example, terraform deployment pipeline, but I can have one single pipeline because I'm using basically the same model, the same tool chain. So I can do things as well here using, for example, argo cd using tactone.

B

I don't need to basically introduce something different, so this actually simplifies and makes some more accessible to developers, also the ability now to provision the infrastructure they need um based on the application requirements, and this is really what we see as the application, centric provisioning and configuration of infrastructure when we start using crossplane in this picture. Next.

B

So as an example scenario, we can see now um how we can actually leverage all these ideas and this concept we cross plane- and we have here a cloud native app where we have three microservices uh ui in front: a command microservices and a query microservices.

B

This is our standard cqrs pattern and on the back end, we have a cloud object store. This is essentially ice3 compatible service from ibm cloud.

B

For this particular example we're using the ibm cloud provider, but of course we could use any other resource infrastructure cloud provider we cross plane, and we are actually running this on a kubernetes cluster, where we have a cross plane runtime installed where the ibm cloud provider, we are also the cross plane help provider.

B

So we do the deployment of the helm application using the help provider and we use uh the cross plane, resources for their cloud provider and composition to configure the cloud object, store and other related resources that I need for my configuration and now, let's take a look next to how actually the insights um I can get look like uh first, a few words also on the ibm cloud provider.

B

This is something that is still an experimental release. We released this last year, I'm currently a maintainer for this project in the cosplaying community.

B

It provides a number of available uh features, such as support for the ibm resource controller api that allow to provision a number of ibm cloud services from the ibm cloud catalog and provides also features such as go templating to shape credentials based on the requirement on application needs and supports, currently also the ibm cloud database api that is used to configure certain characteristics of ibm cloud database services such as auto scaling or scaling a white list, etc, and also we support currently the im api.

B

So we can actually configure also security constraints um around the services we also allowed to import existing cloud services in the provider and as a roadmap. We are currently adding more support for more cloud apis from ibm cloud and looking also a code generation from open api definitions of the provider.

B

Let's take a look now to the kind of insights I can get when I basically run that exemplary application into my single pipeline.

B

So, first of all, I can get information about the configuration of my deployment and, in this particular case, um I'm getting uh through my pr that there is some issue uh as a comment in my pr that there is some issue with the resource limits for my container so the developer.

B

I will know that I need to adjust those resource limits so that I can pass the checks and then I get also some report on vulnerabilities, so packages that I'm using in my application in my micro services. So I had to update those uh packages to to the latest version.

B

uh And finally- and this is the say- the interesting part that uh crossplane allows- I can get in the same pane of glass- also information about the security of my infrastructure configuration and all this configuration, of course uh is amount dictated by the security controls such as nist security controls, so other standards that the compliance officer set up for me as a developer and then, of course, I get a more clear indication of exactly what I need to do in order to be compliant to those controls. For example.

B

In this case, I need to make sure that the cos service um only accept the ranges of ip um to to basically invoke the service. I have to make sure that I set up a log dna for logging and tracking, basically, the api calls to the service, etc, etc.

B

So this basically allow me now to have this very clear feedback for the developers and then I can actually make sure that my application is compliant to the security controls that we have set up thanks.

A

Thanks paolo so we're thinking like what will be the sustainable security model right. So there's some thoughts like if you make a security, a default configuration for every cloud service, so that would essentially means that as a developer, whenever I create some cloud resource, it is by default. It is secure. I'm I'm asked by uh physically it's mandatory for me to provide all the necessary security controls or security configurations, and only configurations that are available are to disable the security cards.

A

So as a developer, I am well aware when, whenever I'm making any security misconfigurations right and whenever I'm doing it right, it's basically obscure for me, it's oblivious to me, so I think the subliminal security is going to be very important. Now. If you look into the stack of uh the standards that are available right so for virtual machines, uh we have standards like cis-ness security control. That guide us on how we should configure virtual machines. How we can we should configure our operating systems.

A

Then we have kubernetes plane. On top of that, we, where we have some cs benchmark, uh which guide us on how we should configure our worker nodes, our master node, our core services for our workloads. We have docker cis benchmark, linux, pci, dss and all not many other security controls for cloud services. We are against some list security controls. So essentially we have security controls across the stack, but the cross plane right. So these are.

A

This is essentially the question that we are trying to ask that at cross plane are the runtime and the runtime providers right. uh Do we consider them as the workload on top of kubernetes and they be subjected to the workload security profile or they are part of the core, kubernetes control plane and need to be subjected to the kubernetes cis uh profile security profiles, or we actually need a separate category to model the security profile for cross plane?

A

uh With that, uh we like to conclude our presentation and thank you for your time and we are open for questions. Thank you. Thank you.

B