Hello, and welcome to Security Patterns for Microservice Architectures. My name is Matt Rabel, and I grew up in the backwoods of Montana. No electricity, no running water for 16 years. We had an outhouse, we had to haul water from the stream, had to walk to the bus stop a mile and a half each way, but in the winter we got to ski. And in reality, it was pretty fun. So I'm a web developer and Java champion. I also work at Okta as a developer advocate. I live in Denver, Colorado with my lovely wife Trish and my two awesome kids, Abby and Jack. I also have a middle child. His name is Hefe, short for Hefeweizen. He is German. He's got a Porsche 911 engine in him and a 915 transmission. I bought him off eBay in 2004, and it took 12 years to make him look like this. I have an expensive obsession with Volkswagen, as you can see. I also have a synchro Westy there on the left. His name is Stout. And if you have a similar problem, I'd love to compare stories either in the comments or hit me up on Twitter with a direct message. So today I'll be talking about microservices and security. And if you've attended a lot of Java conferences, you'll think that everyone uses microservices. It's a trendy topic. Developers everywhere interested in learning more about it. And for good reason too, microservice architectures are a technique for delivering code faster. Chris Richardson is a friend and expert on microservices. He suggests a helpful guideline in a recent blog post. If you're developing a large complex application, you need to deliver rapidly and reliably, then a microservice architecture is often a good choice. So Chris Richardson also runs microservices.io, which lists numerous microservices patterns at the bottom. I noticed that access token is the only item under security. And I was like, whoa, that's a little limited, I think. The information on security patterns for microservices should be much broader. So map to the rescue. Today I'll describe 11 patterns to secure your microservices. And not everyone needs these patterns, just like in Chris's listing. And so I hope you find some of them useful. And I did write a blog post about this, so I'll give you a reference to that at the end if you want to actually read instead of watch. And I'll also list it in the comments or the description below. So just to give you a brief overview really quick, we're going to talk about being secured by design, scanning your dependencies using HTTPS everywhere, using access and identity tokens, encrypting secrets and protecting them, how to verify security in your delivery pipeline. How to slow down attackers using Docker's rootless mode using time-based security, scanning Docker and Kubernetes config, and knowing your cloud and cluster security. All right, so number one, be secure by design. Secure code is the best code. Secure by design mean you actually bake security into your architecture and your software design from the very beginning. And if you have user input, make sure and sanitize that data and remove malicious characters. I asked a friend of mine, Rob Wynch, widely considered a security expert, he is the spring security lead, about user input and sanitizing data. And what he said was that it makes sense to design your code to be secure, however removing malicious characters is tricky at best. And a lot of it's really about the context and where your characters are coming from. JavaScript has cross-site scripting, SQL has SQL injection. But if you're removing apostrophes and you're worried about JavaScript or from someone's name, then obviously people with an apostrophe in their last name are going to be upset. So it's very important to just know about the context where these characters are coming from. So what he recommends is that the characters are properly encoded for that context rather than trying to limit the characters or strip them out. As engineers, we're taught early about the importance of creating well-designed software and architectures. You study it, you read about it, and you take pride in it. When you developed a system that works well and has, you know, plugability and extensibility, you're really proud of it. And so design is a natural part of building software. And well-known security threats should arrive and drive design decisions in security architecture. So reusable techniques and patterns provide solutions for enforcing the necessary authentication, authorization, confidentiality, data integrity, privacy accountability, and even while the system is under attack. You might be asking, what about OWASP? So if you haven't heard of OWASP, it's the Open Web Application Security Project. And it's a nonprofit foundation that works to improve the security of the web. And they're one of the most widely used resources for developers and technologists to secure the web. And they provide and encourage tools, meetups, education and training. It's a great resource, but this is a great quote from Johnny Christmas on an InfoCube podcast called Johnny Christmas on Web Security and the Anatomy of a Hack episode. It's great. And I really like what he says. He basically says that the OWASP top 10 hasn't really changed all the much in the last 10 years. And despite being the number one approach to educate defensive engineers on how to protect their apps, SQL injection is still the number one problem. So even though we tell everyone all the time, watch out for SQL injection, they still make the same mistakes. This is why security precautions need to be baked into your architecture and your design. It shouldn't be an afterthought. So I like the example from the Secure by Design book. This was written by Dan Berg Johnson, Daniel Dogen and Daniel Solano. I apologize to any of those guys if I said their names wrong. They show you how you can develop a basic user object that has a username and displays it on a web page, for instance. If you accept anything for the value of the username, you're open to crossite scripting. If you let a script tag in there and it has some malicious JavaScript, then obviously displaying that on a web page if you're not escaping the HTML is a bad thing. So you can fix this with input validation like the following. Where we have a username, first of all, we verify that it's not null in the constructor. And then we have a validate for xxs method that basically strips out any sort of malicious characters or maybe it fails if there are any in there. However, this code is still problematic. Developers need to be thinking about security vulnerabilities. Developers have to be security experts and know how to use the validate for xxs method. And it assumes that any person writing the code can think of any potential weakness that might occur now or in the future. So a better way to do it is to design a username class sometimes called a domain primitive that encapsulate all of the security concerns. So here's what that might look like. You can see it's got a min length, a max length for validation. It's also got a regex for its valid characters. And then in the constructor, it makes sure all those things are true before it sets the value. So then you can use that in your user class just as a regular parameter into the constructor. So obviously for developers, that's much easier to use. And your design makes it easier for developers to write secure code. So writing and shipping secure code is going to become more and more important, especially as we put more software in robots and embedded devices, because sometimes those don't have an internet connection and they can't update themselves. So that's why I think it's very important to design secure code by default. Number two, scan your dependencies. So third party libraries typically make up maybe 80% of an application's code. Many of those libraries we use to develop software have dependencies on other libraries and those might have dependencies on other libraries. Those are called transitive dependencies that can lead to a large chain of dependencies, some of which might have security vulnerabilities. So you can use a scanning program on your source code repository to actually detect if there's any dependencies that are one out of date or might have security vulnerabilities. So you can use automated software to actually create pull requests against your source code repository and then you can fix those pretty easily. So you want to make sure and scan for vulnerabilities not only in your master branch, but also in your deployment pipeline as you're going to production. Another thing I like to do is run it on released versions of code. A lot of times people will tag releases, so make sure and run it on those tags because something could have gone out of date while you're in production. Then any new code contributions, obviously for any pull requests, have some sort of automated system that verifies there are no vulnerabilities in your dependencies. Rob Wynch recommends watching the application patching manifesto. This is a talk that was giving at a conference, I think, Locomocosec by Jeremy Long. And in this video he mentions that 25% of projects don't report security issues. This is from a sneak survey. Security only add release notes and only 10 actually report vulnerabilities. So you can watch that video, there's a link at the bottom there, and it really explains how you should always use tools to update your dependencies because manually just doesn't happen that much and people aren't really reporting those vulnerabilities a whole lot. So if you're a GitHub user, you can use dependabot to automate everything via pull requests and GitHub also has a feature called security alerts that you can turn on for your projects to see when there are vulnerabilities in there. Here's what it looks like when someone reports a vulnerability and dependabot creates a pull request. You can see this update includes security fixes, it's got the vulnerabilities listed, the release notes and the commits, and then of course you should have CI running on that and it reports if all checks pass. So dependabot will check for updates, pulls down your dependency files and looks for outdated or insecure requirements. It opens pull requests just like this one's and then it gives you the ability to actually close it yourself and say no, I'll do the upgrade myself or merge it in if it looks good. You can also use more full featured solutions like sneak or JFrog X-ray. I've heard sneak called sneak and snake, but I think it's sneak. So I'm going to stick with that. Number three, use HTTPS everywhere even for static sites. So if you have an HTTP connection, switch it to HTTPS. Make sure all aspects of your workflow from build files, Maven repositories, Gradle repositories, you know, Node repositories to XSDs in your XML files refer to HTTPS URIs. HTTPS is an official name, TLS, and you might have heard of SSL in the past, but TLS is the better name to use nowadays, Transport Layer Security, and it's designed to ensure privacy and confidentiality and integrity between computer applications. So how HTTPS works is a lovely site with a comic. If you want to learn more about how it works, it's great because it has this guy that says why do we need HTTPS, this elephant, and then there's this cat that's like privacy, integrity, and identification. And then you got the certificate cat and the compugter and the browser bird. And then they go on to show that how a message is not encrypted when using HTTP and a crab can be a man in the middle or a crab in the middle and potentially, you know, change the message and make it evil. But HTTPS is easy. Troy Hunt has a really nice site called HTTPSisEasy.com and it's four short videos, five minutes each, and basically shows dead simple how to set up HTTPS on your site. So I did mention that HTTPS should be used for static sites, too. And people often laughed at that and they continue to laugh at it. And I love this tweet from Troy Hunt, where someone actually, you know, is basically saying, you know, HTTPS is easy, but we don't need it. And Troy says, that's perfect. I've been looking for a volunteer. And then he publishes a blog post and a video on how he goes through and hacks that static site. And surprisingly, what really the problem is, is where you're coming from. So he talks about how you might be in a hotel room and you're trying to access a HTTP site and the hotel will actually inject code into the page. So it might be JavaScript for an ad or it might be something similar. If you're on a airport network, similar, those might be able to inject content into the page. If you're on an ISP at your home, similar thing. So it's kind of to protect you more than the website in the static site case. So try to use HTTPS for those to protect your users. So HTTPS or TLS, you'll need a certificate to use it. So it's a driver's license sort of thing that serves two functions, a grant permission to use encrypted communication via PKI or public key infrastructure. And it also authenticates the identity of the certificate holder. And you can get free certificates from Let's Encrypt and you can use an API to automate renewing them. And there's a great quote and really a background on Let's Encrypt from Sergio D. Simone in a recent InfoQ article. He says, Let's Encrypt launched on April 12, 2016. So not that long ago, less than four years ago. And somehow transform the internet by making a costly and lengthy process, such as using HTTPS through an X509 certificate into a straightforward, free and widely available service. Recently, the organization announced it had issued one billion certificates overall since it's a foundation and it's estimated that Let's Encrypt has doubled the internet's percentage of secure websites. So yes, Let's Encrypt, you rock. So Let's Encrypt recommends you cert bot to obtain and renew your certificates. It's a free open source software tool maintained by the Electronic Frontier Foundation. So it lets you choose your web server in your system, then provides the instructions. Here's the instructions for Ubuntu with Nginx. You'll SSH into the server, you'll add cert bot PPA to your list of repositories, and then you'll run the command to install cert bot on your machine.  And then you can test the automatic renewal of it on my website on RableDesigns.com. We actually use a cron job, so it renews it every 90 days. And then you won't need to run cert bot again. You can test the automatic renewal and all that, and then you can confirm it worked. And if you want to check that you have the top of the line installation, you can use SSL Labs for that. So you might ask, why do we need HTTPS inside our network? That is an excellent question. It's good to protect the data you transmit inside your network because there may be threats inside your network. What I've heard is a lot of hackers have access to gigabytes of credentials. And so if they're going to try to hack your network, typically first they just have to guess an email. And since most companies use first name dot last name or first initial last name, it's pretty easy to guess someone's username. And then they can basically grab all this information from the dark web and be able to attack your network. And so phishing, obviously very effective. So effective that a lot of companies won't pay to have a security company do an audit and test for phishing because they know it's going to work. And so in both cases, phishing, guessing someone's credentials, the attacker could gain access to your network and then holy cow, they're inside. And that's why you want to protect your data inside your network. So you might wonder about, we're talking about REST APIs and microservices a little about GraphQL. GraphQL is a very popular alternative to REST APIs where you say what you need from the client and the server only gives back what you need. Well, the good news is GraphQL runs over HTTP so there's nothing really new that you need to do there. The biggest thing you'll need to do is keep your GraphQL server up to date because GraphQL relies on posts for everything. And this means that your server will be responsible for the sanitizing or looking at that input and making sure it's correct. So always make sure your server software and your client GraphQL software is up to date. And here's an example. Apollo is a platform for building a data graph and it has client implementations for React and Angular. So if you'd like to connect to a GraphQL server with OAuth2 and React, you just need to pass an authorization header. Right here you can see in this set context, we're setting operation.setContext and we're setting that authorization header with a bear token. And so if you were to make a REST call in a React app, it would look very similar. You would still set a header and authorization header and go for it that way. There's also Rsocket. So you might be familiar with Rsocket in case you aren't. It's a next generation reactive layer 5 application communication protocol that's designed for today's modern cloud native microservice applications. So what does that all mean? It means it has React semantics built in, so it has the ability to communicate back pressure back to its clients and provide more reliable communications. It has implementations for Java JavaScript, go.net C++ and Kotlin. And it enables you to do things like request response, right? A stream of one or request stream, so a stream of many, fire and forget with no response and channel, which is bi-directional streams. So Netify is one of the main contributors to Rsocket, as well as Facebook, I believe. And they're basically a cloud native application platform that's built on Rsocket. And Spring Security 5.3 has security support for Rsocket. So as far as I know, you can use Netify or you can use Spring Security. I'm sure there's other solutions out there for securing Rsocket, but I'm not aware of them. If you want to learn more about Rsocket, I recommend getting started with Rsocket to the blog post on the spring.io blog. And it's a great way to just see how to get up and running. It takes you about 15 minutes. You can see it was just written in March. So number four, use access and identity tokens. So OAuth 2.0 provides delegated authorization and it has since 2012. One ID added federated identity on top of OAuth 2.0 in 2014. So together they offer a standard specification that you can write code against and have confidence that it will work across multiple identity providers or IDPs. So the spec allows you to look up the identity of a user by sending an access token to a user info endpoint. And you can look up the URI for this endpoint using OIDC discovery. Step number one in this slide. Which provides a standard ways to get the user identity. So it's a really nice, simple way. Now simple, let me clarify that. Once you know about OAuth and how it all works, then it seems simpler. But before that or without it, you're just going to write your own authentication. So try not to do that. If you're communicating between microservices, you can use OAuth 2.0's client credentials to implement secure server to server communication. In this diagram, you can see that the API client on the left there is one server and the API server is another or the API service. So they're both talking to the same authorization server, but they have secure communications between them. And if you're using OAuth 2.0 to secure your microservices, you're using an authorization server. So the typical setup is a many to one relationship where you have many microservices that talk to a single authorization server. The pros of that are the services can use access tokens from that server to talk to each other. There's a single place to look for all your scopes and other definitions and your claims. It's easier to manage. It's going to be faster because it's less chatty. Now the cons are it opens you up to rogue services causing problems, right? If someone adds a new service that uses that same authorization server, then yikes. And if one service token is compromised, all services are at risk. And there's vague service boundaries because they're all talking to the same single identity engine. And so an alternative to that a more secure way is to use a one authorization server to each microservice. And if they need to talk to each other, you have to make those authorization servers trust each other. So there's definitely more work there. The pros are clearly defined security boundaries. It's slower because it's chatty or talking over the network. There's many authorization servers. There's many scopes. You have to look at each one to see how they're configured. And it can be hard to document and understand. So what I recommend is use a many to one relationship until you have a plan and then document how to use a one to one if you decide to go that way. So use Peseto tokens over JWTs or JOTs. So that's the short name for JWTs, JOT, it's actually in the spec, J-O-T. So JSON web tokens has become very popular in the past several years, but they've also come under fire. Also because there's a lot of developers that try to use JWTs as server side session tokens. And I like to think of Peseto tokens as JSON web tokens are good parts. You might recognize that this is a doctored image of JavaScript, the good parts. So there's a lot in JavaScript and then there's a good parts. Same thing with JOTs. There's a lot in JOTs and then there's a good parts, which is Peseto. So one of the main selling points of JWTs is their cryptographic signatures. And because JOTs are cryptographically signed, a receiving party can also get the JWT and validate that as trusted. But you know what else does that? Web frameworks and sessions and session tokens, they've been signing those and their cookies and sending them across the wire for years, for 20 years. So why reinvent the wheel there? This means you get the exact same benefit as JWTs and their whole signatures. And you don't have to add processing on your server or client.  And he's even produced a t-shirt.  So Peseto stands for platform agnostic security tokens. And it's everything you love about Jose, which is the JavaScript object signing and encryption spec, which includes JWT, JWE for encryption, and JWS for signing without many design deficits at plague the Jose standards. So long story short, using Peseto tokens isn't as easy as it sounds. If you're using an identity provider, they're probably still using JWTs. If you want to write your own security, which I don't recommend, you can use Peseto tokens. And hopefully someday a lot of the identity providers will add support for Peseto tokens. Public Peseto tokens are not encrypted. They are digitally signed. If using Peseto tokens that aren't public, you can actually make them so they are encrypted. This means if attacker gets a hold of your Peseto token, they'll be able to see all the data that it contains, but they won't be able to modify it without knowing about it thanks to the digital signatures Peseto's use. Five. So when you develop microservices that talk to authorization servers and other services, the microservices likely have secrets that they use for communications. For instance, an API key, maybe a client secret, maybe credentials for basic authentication. The number one rule for secrets is don't check them into source control. Even if you develop code in a private repository, it's a bad habit to get into. Don't do it. Don't start. That's basically to cause trouble. You can actually search on GitHub for remove client secret or remove password and there's thousands of commit messages with the history that shows what the password was. The first step to being more secure is to store your secrets in environment variables. So that's a little better than in your source control, but that's only the beginning. You should do your best to encrypt your secrets and maybe use something like hash accord vault, which has spring support or Azure key vault to actually store your secrets and retrieve them in a secure manner. My coworker Randall is also a big fan of Amazon's key management service, also called KMS. And the way it works is you generate a master key using KMS, right there. And then each time you want to encrypt data, you ask AWS to create a new data key for you. All right, new data key. And then a data key is unique representation or encryption key that AWS generates for each piece of data you need to encrypt. You then encrypt your data using that data key, and you will then merge the encrypted data key with encrypted data to create an encrypted message right here. So the encrypted message is your final output. And that's what you can store in a file or storing your database. And that is very secure. So you could probably even store it in an environment variable if you want it. Number six, verify security with delivery pipelines. So dependency and container scanning should be a part of your source control management systems. And so I used to think that, you know, scanning dependencies, palm dot XML files, package dot JSON files, probably good enough. But no, you need to scan your container configurations as well, right? Using infrastructure as code, basically means you just have YAML in your source code repository. But you should also perform tests when executing your CI and CD pipelines. So dev sec ops, you might have heard that term used to be DevOps, right? And that's all we called it. We were happy with that. It's the term that many recommend instead of DevOps to emphasize the need to build security into DevOps initiatives. I just wish it rolled off the tongue a little easier. Dev sec ops. Oh, well, dev sec ops, you know, injecting security into delivery pipelines involves security unit tests. So writing unit tests for your security code, also static analysis. So as part of your process, if you have static code, especially being able to analyze it and see if there's any, you know, bugs in there, there's many tools for that, for many different languages and dynamic analysis, security testing. So abbreviated SAST, S-A-S-T static and dynamic D-A-S-T. And unlike SAS, D-A-S-T examines your application from outside in its running state and then tries to penetrate or do malicious things to it, much like an attacker would do. And so to learn more about a continuous hacking way of actually making sure your delivery pipelines and CI works well, check out this article from Zach Arnold in Austin Adams. It's how continuous hacking of Docker containers and pipeline driven security keeps Y green safe. I think that's it. Y green energy fund. It's a financial corporation that provides property assessed clean energy financing. Great article by them. You can see there's a bitly link at the bottom. Now you can go and read the whole thing. They basically recommend creating a whitelist of your base Docker images, pulling only cryptographically signed base images, signing the metadata of a published image cryptographically so you can check it later. Using only Linux distros that verify the integrity of the package, using the package manager security features, only allow HTTPS for third-party dependencies and don't build images with a sensitive host path as a volume amount. But what about the code? So Zach and Austin use automation to analyze it too. They run the static code analysis for known vulnerabilities. They run those automated dependency checkers for the latest versions. And one of the things that they said that they really like to do is the spinning up of the service and running automated penetration testing bots on the running containers. One of the ones they recommend is Zet Attack Proxy from OWASP. The URL for that is Zaproxy.org. I've used that a couple of times. And it allows you to give it a whitelist of URLs. And they'll go crawl those and look for vulnerabilities. You can also actually record a session. So you would turn it on and set your browser to point to Zet Attack Proxy on a different port. And then it records your browser session. And then it plays it back and tries to do all kinds of malicious things. So I've used it, works great, highly recommended. Number seven, slow down hackers. If someone tries to attack your API with hundreds of gigs of username and passwords, it could take a while for them to authenticate successfully. Well, if you slow things down, so instead of making 10 or 100 attempts a second, they can only make one attempt a second or one attempt every 10 seconds. It's just not worth their time. They're likely to go away. And you're more secure because of that. So you can implement rate limiting in your code. And a lot of times you can do it on your microservices architectures API gateway. I'm sure there's other options, but these will be most likely the most straightforward to implement. And most SaaS companies have rate limiting built in to prevent customer abuse. We had to have API rate limits for not only our API, but our email rate limits as well. And those protect our customers against denial of service attacks. It also protects us from people trying to hack in. Number eight, use Docker rootless mode. So the developers of Docker designed this feature to reduce the security footprint of the Docker daemon and expose Docker capabilities to systems where user can gain root privileges. So if you're running Docker daemons in production, this is definitely something you should look into. However, what I've seen is most people with microservices are using something like Kubernetes to run their Docker containers. So if you're doing that, you'll need to configure the run as user in your pod security policy. Make sure it's not running as root. Number nine, use time-based security. So the idea behind time-based security is that essentially, your system is never fully secure. Someone's going to break in. Preventing intruders is only one part of securing a system. Detection and reaction are essential too. So you can use multi-factor authentication to slow down intruders, but also to help detect when someone with elevator permissions authenticates into a critical server, because that shouldn't happen a whole lot. You don't really need to log into your domain controllers and change things a certain amount. So if you have something like a domain controller, you should send an alert every time someone with elevated privileges like administrator logs in and notify the rest of the team. And this is just one example of trying to detect anomalies and react to them quickly. There's a great book called Time-Based Security from Win Schwartau that many security experts recommend reading to learn more about this whole concept. It is available for free on his website. So I do have a funny side note from my buddy Randall again, his thoughts on MFA.  And it was funny because he gives two perspectives. One is the security administrator's perspective, which is like, I love MFA so much. It makes my job so much easier. But then the developer perspective or the user perspective is like, really, I have to go find my phone again and be able to authenticate by walking across the house, getting my phone, and then entering the code. So what he recommends is basically trying to use adaptive multi-factor authentication. So if your security provider has that, try to use it. And that will usually make it so you don't get prompted as much. It trusts you based on where you are, what country you're in, and things of that sort. Number 10, scan your Docker and Kubernetes configurations. So your infrastructure is code. Make sure and scan those. Docker containers are very popular in microservices architectures. Our friends at Sneak have published a 10 Docker Images Security Best Practices Guide. It's a great guide. You can print it out, put it on your wall, and now you know. So prefer the minimal base images instead of not only whitelisting them, but also look for the base ones, not just the ones that are built up with more things on them. Use the least privileged user. Sign and verify your images to prevent those man in the middle attacks. Find, fix, and monitor for open source vulnerabilities. Of course, they do that, so they're going to recommend it. Don't leak sensitive information to Docker images. Use fixed tags for immutability. Use copy instead of add. Add can specify URLs. And so if you're not using HTTPS, that's going to be an issue. Use labels for metadata. So one of the things you might have heard about is a security.txt policy that you can put in there and then people know who to contact if they find a security vulnerability. Use multi-stage builds for small, secure images. And use a linter, such as Hatterlinter, which shows a warning for any errors that it finds in your Docker files. And you should also scan your Kubernetes configuration. But there's much more than that. So I'll cover Kubernetes security in the next section. There's also a great blog post from the white source folks on top five Docker vulnerabilities you should know. And I didn't list them out here because some are more to do with PHP and certain libraries. And I figured you could go look it up. Number 11, so boom. Know your cloud and cluster security. If you're managing your own cloud or even a cluster in a cloud, you're probably aware of the four C's of cloud native security from kubernetes.io. Basically code, container, cluster, and cloud. Each one of the four C's depends on the security of the squares in which they fit. So it's nearly impossible to safeguard against poor security standards in cloud, containers, and even code if you're only addressing it at the code level. However, when you deal with these areas appropriately, then adding the security to the code obviously augments an already strong code base. So the Kubernetes blog has a detailed blog post from Andrew Martin titled, 11 ways not to get hacked. And Andrew offers these tips to harden your clusters and increase the resilience in case a hacker does come along. This blog post is from 2018. And not a whole lot has changed. Statically analyzing your YAML, still a thing. Rotating your encryption keys. Obviously use TLS everywhere. Great idea. Use a third party auth provider. Also a great idea. Run a service mesh. Now, I do think there's a fair amount of hype around service meshes since 2018. And that hasn't made a huge difference. A service mesh provides critical capabilities, including service discovery, load balancing, encryption, observability, authentication authorization, and circuit breakers, and everything. So you don't have to actually do it within your code, which is nice. You can just do it with sidecars. This is a diagram from Red Hat that shows what a service mesh is and how sidecars can actually do a lot of that infrastructure related thing. So running a service mesh, for instance Istio, might allow you to offload security to a shared battle-tested set of libraries. Still, I don't think it's really simplified the deployment of the next generation of network security, like the blog post said it could. So yes, look into running a service mesh. I don't know that it'll solve all your problems, though. I hope you've learned something from the security patterns for microservice architectures, and it's made you a more security-conscious developer. It's interesting to me, though, that of this list, the first five are the only ones that pertain to developers on a day-to-day basis. Six to 10 apply to more DevOps or DevSecOps folks. And since most of these apply to your whole architecture and your whole product, it's very important that you're doing microservices right, and you have your developers and your DevSecOps folks on the same team. That's how microservices should be done. A team owns a product all the way from concept to production and managing it in production. Once you can do that, according to Conway's law, then your organization will be very independent as well and can communicate via these teams, and you can scale to the moon. So action. Design with security in mind. Scan your code. Always use TLS. Use OIDC and OAuth2 because friends don't let friends write authentication. Plan for attacks and study time-based security. Look into that and see how it can help you prepare for when the attacks do happen. If you want to learn more about API security, a bunch of developers at Okta, including myself, wrote this book, and you can look at it online. API security, you can also, I believe, go to Amazon and purchase it, but it's available online, so just read it there. I think it's about 100 to 150 pages, and it's got a whole lot of information about securing your APIs. We write a lot of blog posts on developer.okta.com slash blog, and my whole team is at OktaDev, we're the developer relations team, and we even have a YouTube channel, so if you look for OktaDev on YouTube, you'll find videos like this one out there.  You can read that on the OktaDev blog. There's a URL at the bottom there, and thank you for coming. You can find me at rabildesigns.com. That's my personal blog. It's got some tech stuff on there, but mostly Volkswagen's. You can find me on Twitter at mrable. My direct messages are wide open, so hit me up any time. I'll upload this presentation to SpeakerDeck, and you can find a lot of the code and the examples I write these days on the OktaDev GitHub. May the auth be with you.


Tell us your full name and where you are from. Definitely. Well, good morning, everybody. My name is Christian Schlegel. And I was born in Germany. I've lived in Canada for about 14 years. And I'm here today with my parents and my brother. Amen. So Christian, can you tell us what is the testimony that you have to share with the congregation today about God Almighty has done your life through the medium of the anointing water? Absolutely. I'm currently studying to become a paramedic. And I've been looking into ambulance companies that will take me in. In the late fall of 2014, I applied to a company called Medivan. And I got a reply from them after I sent on in all my applications. And I got a reply from them. This is the first email right here that states, basically, thank you for applying. But currently, we are not hiring. So anytime in the near future. My parents came to visit this prayer line about a month later, not a month later, about a month ago. And we've heard about TB Josh when the anointing water. And so when they came back, it was in February. They came and visited here. And they brought some anointing water back home to Canada. And then I took that anointing water. And I said, God, I know that you said in your word that if you open a door, no one is able to close it. And if you close a door, no one is able to open it. And I said, God, I believe that you use a medium, that you can use a stick to part the sea. You can use a dead man's bones to bring life. And I said, Father, I believe that you are my savior. You're my deliverer. And nothing, if you're on my side, God, nothing could go against me. And I started praying. I took that application and I sprayed the water, declaring the word of God. About four days, about a few days later, I got an email from them. This is the second one right here. And stating, I do not know if we told you or not, but there's a position available. And if you're interested, we would like to look into your application. And I replied to them. And I said, oh, yes, definitely. And I told my mom. I'm like, that is God. That is God. And I got hired with the company. Praise the Lord. So when you had originally applied for this position, you can see on the very first email that you got, it says that you had sent this email on December, or you had received this email on December 29th, saying that there was no position for you. And during that time, all the way leading up until February, was there any contact at all from this company? During that time, no. And so after you received the anointing water when your parents came, then four days later on, it says on the second piece of paper, here it is, February 25th, that was when they were giving you that interview directly after you had prayed with the anointing water. Yes, ma'am. Amen, amen. Put your hands together for wonderful Jesus. So Christian, now that you're here and you've received this amazing breakthrough that from Jesus Christ, giving you a job and making a way where there seems to be no way, what advice can you give to the people in the congregation who might be facing some similar situations? I'm no more different than you. If God can do it for me, if God can do it for you no matter what circumstances, no matter what mountain you're facing, our God is greater. Hallelujah. Amen, amen. Let's give our God a wonderful round of applause.


You can notice already one thing might happen that I can't talk anymore. That's really unfortunate. And the other thing, my laptop might run out of battery life and I only have a European charger, but I hope we will be fine with both. Yeah, Matthias talked a lot about not only about using Elasticsearch for log analyzers, like doing centralized logging with Elasticsearch and that's a really, really good use case. And if you're not doing centralized logging already for big applications, it's really, really helpful. And for developers, that's a really, really great thing to have. The last project I did, we had centralized logging with Elasticsearch. Elasticsearch for business reporting and Elasticsearch as a search engine, all in the same project. So that was really nice to have. Yeah, I'm Florian. I'm from Germany originally. And I'm doing a lot with search, obviously with Elasticsearch. Matthias just reminded me that this is the old logo and I shouldn't use it anymore, but I like it better than the newer stuff because of the glasses. But I'm also doing a lot with Lucene and Solar as well. So I'm more on the side of doing application development, but also a bit of centralized logging and stuff like this. And besides the search stuff, which I mainly do as an independent developer and consultant, I'm a classic backend developer, I would say, all in the Java landscape, like doing classical stuff like Spring and Hibernate, and also different databases like MongoDB, MySQL, and all the different microservice technologies that are available and taught right now. Yeah, I'm extremely happy to be here today. As you might notice, I'm doing a user group, the Java user group in my hometown as well, or I used to be the organizer. We are maybe the same size of people, I guess, normally doing talks every month, so it's really fine to be here as a speaker at the Java user group here. And I'm also one of the organizers for the Search Meetup, which is more specialized. I think there are two meetups like this in Singapore as well, but there haven't been any talks for a while. Yeah, Singapore, I really, really like Singapore. I'm here for the fourth time, I think. Yeah, that's one of the pictures that was available for free. So I took care that I don't have any problems with licensing. So are there more buildings right now? Okay, I did notice, sorry. Yeah, okay, so maybe that's because I'm mainly here for the food normally, so I really, really like the food in Singapore. And all of this sums up, it's a really nice city, I like the food. So currently, I'm looking for work in Singapore, so I'm looking into relocating here. Yeah, but that's. Yeah, maybe if you have interesting jobs, I would be happy to talk to you. Yeah, that's enough about me. This is about Elasticsearch, of course, and the Java clients for Elasticsearch. But for now, Matthias showed already some parts of how Elasticsearch works. But let's take one step back and look at the basics again. This is a definition from the Elastic website. Elasticsearch is a distributed, JSON-based search and analytics engine. We heard a lot about this already. Designed for horizontal scalability, maximum reliability and easy management. I really, really like this definition because it's a very, very concise definition containing a lot of the different aspects of what Elasticsearch is. Important for us right now, let's first look at the aspect that it's a JSON-based search and analytics engine. What does it mean? First, let's have a look at what search is generally. Like this is something maybe everybody of you has seen already and used already maybe. This is the GitHub website where you can just search for different projects or code snippets or something like this. You're doing a keyword search. So search normally is keyword search. Easy. I think that one of the aspects that distinguishes Elasticsearch or search engines generally from databases is the notion of relevance. We have already heard about already. And you can see that when searching for Elasticsearch, it is very, very likely that somebody searching for this term is meaning the project Elasticsearch. And this is also what is happening here. GitHub already manages to have this project on the first position, even though there are other projects with the same name. So I don't know what GitHub is doing internally, but I could guess that they are also using the popularity of projects for boosting this. So this is important for search, that the user gets the documents they are looking for at the first places. Besides that, from this screen, you can also see a lot of different aspects supporting features of search. Like there's this highlighting features, which lets you see where a match occurred. So this can help the user to see if the document really is the one he is looking for, or she. And also you can sort by other aspects. There's a lot more supporting features. For example, this here, the faceting, we already have heard. It's for refining the current search. And this is done using the aggregations feature of Elasticsearch. All of this search like this can be built using Elasticsearch. And in this case with GitHub, it's Elasticsearch as well. They're using it for a really, really large amount of data. And working fine, I think. Okay, if you want to build something like this ourselves, of course, we first have to install Elasticsearch. That's really, really easy. All we have to do is download the artifact. Like it's an archive, like a zip archive, but there's also TowerGZ as well, unpack it, and run a script. All you need to have available is a Java runtime. And that's all you have to do for now. Once it's running, you can just call it using HTTP. I am using Curl here, the command line, HTTP client. Just doing a request on the default port of Elasticsearch. 9,200, and Elasticsearch will answer with this JSON document here. It's just a bit of information, like the underlying Lucid version that is used for the search features or the build date of the libraries. But for us, it's important the application is running. That's what you can see here. And Elasticsearch is used in JSON everywhere. So we will see that a lot. Okay, but we really want to build an application. And for me, what is very important is with all the good food in Singapore, I of course want to be able to find it. So I will be indexing different dishes in Singapore. Like this is the chicken rice, very popular, I like it. And this is a classic document that can be indexed in Elasticsearch automatically. You can see different aspects of JSON documents available here. Like there's simple strings, but there's also this kind of lists or array where you can have multiple strings. And also you can have sub-document like here with the favorite section. And some numeric types, Boolean types and the geotypes we already have heard. So where are we putting this data? This is, we just added two fragments to the URL here. The first one is the index name, which is just a logical collection of documents. It's like a database in the relational world. You can just choose anything. The thing behind it is the type of the document and the type determines the structure, how it will be stored in Elasticsearch and how it can be searched afterwards. It's very important to know that even though we have indexed another document before, there's no need that all of the documents need to be the same. So even though it's very, very advisable normally in applications you will have documents that are very close in structure. But of course you can leave parts of the original document out or add other attributes. So it's a schema-free style of development. Like there is a schema in the background, but for the user you can really evolve the documents easily. Once we have indexed those documents without doing any configuration, we can already search them. This time using a GET request on this underscore search endpoint. And then in the easiest case we can just add one parameter containing the search term. And this works without any configuration. It returns the two documents we have indexed. And in the list here it will also contain the original source of the documents we have indexed. So without doing any configuration work, you can easily start Elasticsearch index documents and search them. Using parameters alone wouldn't work. We want to have a lot of search features and the queries can get rather complicated. That's why with Elasticsearch normally you don't do the parameter stuff, but you're using the so-called query DSL instead. This is now a post request that sends a JSON body to Elasticsearch for search. And this JSON structure here describes the query that we are about to do. In this case we are having one match query here. Match query is the kind of, it's used most often for the full text search stuff. We are querying on a special field that is a combination of all other fields. And say we want to have rice contained anywhere. And then we're adding another filter here that queries the tags. And this is the keyword feature that was introduced in Elasticsearch 5. So this means this needs to be an exact match down here. But this is a free text match. So there might be more processing over here. So this is the way Elasticsearch is working. At first it might seem a bit of overhead like passing this huge JSON structure just for search. But it's really, really useful. And it's easier to get started with it and even it's easier to maintain it after a while. So the query DSL is also the place where you would request a lot of the other features like highlighting aggregations and stuff like this. You can do a lot more with it. And also normally you don't use, for production applications, you don't use this feature that you can just index documents. You would normally define a mapping for them. But those are features that are out of scope for now because we just want to look at how we can use Elasticsearch with Java. But first let's look at another aspect that is also contained here in this definition. It says that Elasticsearch is distributed and designed for horizontal scalability, maximum reliability. This of course means that starting one node only is not enough normally. Like what we can do is we will have one Elasticsearch node and our application somewhere. Application can be Java application or even something else. This will access Elasticsearch and use it for search or anything else. Once this node goes down, our application would be down as well. And this is not what we want to have with a highly reliable application. So what you normally are going to do is to have multiple of the Elasticsearch nodes. Those will form a cluster automatically. It used to be more magic in the background. Right now you have to configure a lot more to have the production mode. Matthias talked about. But still it's rather easy to manage the cluster. Still you can talk to one node only and it will take care that it will ask the correct node where the data resides for the information. So this feature is for high availability. We don't want the cluster to go down totally. And secondly, it's for maintaining very large data sets that fit on one node. So those are the two aspects here. Okay, let's recap. That's a basics of Elasticsearch. It's a Java-based search server. It uses HTTP and JSON everywhere. The search and filtering query DSL is very powerful. There are so many queries for different use cases. Often you have to combine them with the analyzing process. And there are lots of features for supporting search, mostly from Lucene, like the highlighting and suggestions, but also custom features like faceting using the aggregation. And very important, it's a distributed system. The nodes can form a cluster. Okay, let's look at the first option. There is two access Elasticsearch from Java. This is also the one that is the oldest. It's a so-called transport client. This was available for Elasticsearch for always, I think. With Elasticsearch 5.0, this is now a separate artifact. You can use it from Maven or here from Gradle. Just say you want the transport client available, so it will pull down some charts, a lot of charts. Then you can do, like, you define a transport address. That is one address for accessing your cluster. In my case, it's running on the local machine. So localhost, port 9300. And then you can build one of the clients from this, the pre-built transport client it's called right now, pass any settings that might be necessary, like when you have a custom cluster name or something like this, and add the address. This client interface can then be used to do everything with Elasticsearch. Like, you can do the classical search applications, you can do the indexing stuff, you can do the administration and monitoring and everything. Let's look at the search part. Again, this is the same query we have seen before. The good thing with the transport client API is that it's very close to what the query DSL does. So what you can often do is, like, you experiment with the query DSL, just typing in in the browser or on the excellent sense plugin, which is now also part of Kibana. And once you are happy about your result, you can just take this structure and nearly one-on-one do this with the Java application. This above here is the code that searches the same query. And if we recall what we had before here, there's a bool query that contains a must section and the filter section, the must section contains the match and the term in the filter. And we can see the same thing here. There's a bool query, contains the must section with the match query and the filter with the term query. So it's really easy going from the query DSL to the Java part again. There's a bit more before here. We are starting the search with the prepare search method. We can give it index and type and then execute it. This is all asynchronously executed. So the action get here is the blocking call. Afterwards, this search response object is the same we have seen before, like the response to a search. It contains this hit sections where we can, for example, get the total number of hits. And this hit sections then has the list of hits themselves. And we can access the original source of the object again. When indexing data, we can go the same way. There are different options available. This time we are starting with one of the builders that are available. Like this is a static import method, the JSON builder. And this is very useful to just construct the object you want to index. So in this case, you can just say, okay, start object and object for the JSON structure and then add field, add array, stuff like this, and start objects again. So you recreate the JSON structure again using Java code. This can then be used with this prepare index method as the source. So this is the document that is then going to be indexed again. You can use a lot of different objects and types for passing as the source document. Like very common is the builder we've seen right now. Just pass it as a string. Like you can use something like Jackson or JSON to build a string-adjacent representation. And there are some convenience methods here for building very simple objects or just passing as a map. So there are different options available. Okay, we have seen it connects to an existing cluster. And you might have noticed that it didn't use the same port that is used for HTTP. That's because it's using the transport protocol. That's why it's named that way. And this is a binary protocol that is also used for the communication inside the cluster. So of course, this is more efficient. So it looks like this. Basically, all of those communication aspects here, it's all binary. What I didn't talk about before is I talked about high availability, but there's only one arrow here going from our application to this node. So if this node goes down, we might be screwed even though there are two or more nodes available because our application doesn't talk to it. That's why the transport client and all of the other two clients I'll be introducing later on has a feature called sniffing. And this sniffing allows our application to retrieve the state of the cluster from one of the nodes and then talk to all of them in a round robin fashion. So it does client-side load balancing. And then when this node goes down, we don't have any problem in our application because it can still talk to the other nodes. Yeah, you can do this by just passing this as a setting, client-transport.sniff and it will automatically do everything for you, do client-side load balancing. Yeah, that's the transport client. The important thing, it has full API support. Like we saw building the queries, it has the full support of the current version of Elasticsearch always because it uses the same code that Elasticsearch is using internally. So you will always be up to date. You don't have to upgrade your client library for new versions. The communication is very efficient because it's the binary protocol and it has the client-side load balancing. But there are also some serious drawbacks with the transport client. Especially that as you're using an internal protocol, you need to be very, very careful with the Elasticsearch versions used in the application and in the cluster. Those need to be nearly the same. I think there are some exceptions. And this makes upgrading a lot more difficult than it should be. You have to take care that your application is upgraded when the cluster is upgraded and the other way around. And this is not suitable for all applications. And also the JVM version? The JVM version needs to be the same as well. And this might be even more dramatic, I think. And another drawback that can be as worse is that it has the dependency on the full Elasticsearch server. When you're pulling down a chow, even though it's a separate artifact right now, this will pull down all the Java code for the Elasticsearch server. And this also means that you will have dependencies on Lucene, on Jews, on different libraries, and especially for existing applications. Or if you're integrating either in a CMS or an online shop, an existing one, you will have some dependencies already and it can be a real nightmare to make sure that all of them work together. And it can be even impossible. So that's why Elastic introduced the REST client with version 5.0. But so far, are there any questions about the transport client or the stuff I introduced? Fine. If there are any questions, just feel free to ask anytime. Okay, of course, this is different now. Our application excesses the Elasticsearch cluster using HTTP instead of the binary protocol. That's the huge difference. Elasticsearch itself will still talk with the transport client, transport protocol, but our application talks to Elasticsearch using HTTP. Of course, this makes it far more independent of the Elasticsearch cluster of the versions, anything, and even of the API. The HTTP API doesn't change that much as the internal stuff. And this is available in Maven Central as well. It's just, instead of transport, you can use REST. And it has far less dependencies. So this is actually, I think, one dependency with some transitive dependencies. It just uses the Apache HTTP client library. So this is a lot easier to integrate in existing applications, of course. So how do you start with it? We saw it on the slide already by Matthias. You can add one or more HTTP hosts that are used for communication. And this is, again, one of the builders, like Elasticsearch is using the builder pattern a lot. And this will create a REST client. The important thing is we don't have that many dependencies. And because of that, there is not much support right now for any query DSL structures building them. So the REST client, as it is right now, is mostly for talking HTTP. And there's not much support for querying and indexing. So for example, this is one example one might do right now for querying Elasticsearch using the REST client. You create one of those HTTP entities. I think this is also part of the HTTP client, Apache HTTP client. And you really pass the string you want to add as a payload. So in this case, it's a match all query because I wouldn't be able to fit a normal query on this slide. But even this might not be as bad as it might seem because when building an application, you don't have that many different queries. So you can even use something like a template engine or something like this, just store your queries in a text file and load them in the application. It could be fine as well. And then you are passing this to the... You just perform the request, say you want to go against this endpoint, and that's basically all. And after that, you can just then retrieve the result of this request. And again, you will retrieve this HTTP entity. And there's a convenience method for just converting it to a string. But after that, right now, you are completely on your own doing something with this string. So you need to maybe use something like JSON path or some features like this to get the information you'd like to have. There will be a lot more coming with this. There will be a separate query DSL. It's talked about, but I'm not sure how long it will take, and I think Matthias as well. But this will be the future of Elasticsearch. So I didn't show the indexing part because it's basically the same, just pass a JSON string in the body. The important thing is the REST client is less dependent on the Elasticsearch version and JDK version. Something which can also be very important, especially for larger operations, there's a clean separation between the cluster and the rest of the application network. Like you don't have to open any ports beside the HTTP port to your cluster, and it's all internal, the communication. This can also be very beneficial when it comes to firewalls. I have seen very bad things happening with some corporate firewalls and the transport protocol. Yeah, it has minimal dependency, which is very good. There's an additional library that supports sniffing. This has some more dependencies. It has a dependency on Jackson and a bit more. But then it can also do the client-side load balancing we have seen with the transport client. There's a lot more like error handling, timeouts, basic auth, and so on. But for now, no query support, no indexing support. That's the state of Elasticsearch 5.0. Elastic didn't have any HTTP client until this version, but you were able to use it even before. By the way, the REST client can also be used with Elasticsearch 2.x versions, so it's not tied to Elasticsearch 5. The chest client is an older client. It's a community project, so Elastic is not involved in building the project. And this is an alternative REST client for Elasticsearch. And it's still maintained. Again, available in Maven Central, doesn't follow the naming, the versioning scheme of Elastic, but yeah. And it has a client object as well, and it can be created using a factory. It's really similar with all the libraries, like you pass in the URL you want to access. You can use multiple threads, and then you have the client that is then also responsible for querying and indexing and stuff. Again, it doesn't have much support for querying, so you will have your JSON string somewhere, and you can either have it in a text file, or you can build it using string concatenation, or you can even use the Elasticsearch classes for building them, but of course then you have the dependency on Elasticsearch again. It's a really similar API, but not the same. It also has some builder classes where you can just build the request and then execute the search. The search result, one way to access the data is it supports this JSON object, like this object structure, so you can really navigate all the way down, but this is not what you do normally with a chest. This is far too complicated, accessing this JSON structure. The good thing about chest is that it supports Java beans. So what you can do is you build a Java bean, classical stuff like having properties and gaites and setters for it, maybe assign a chest ID, like the field that we will have, in this case the auto-generated ID, and that's all you have to do. Then you can just make sure the chest populates this class from the JSON it retrieves from Elasticsearch, which is really nice, of course. Again, you can just use your Java beans for anything you might want to do. Of course, the same is true for indexing. You can just pass Java beans to chest and those will be indexed, which is really nice. It's an alternative HTTP implementation. It has been around for a long time, but I think not that few people are using it, especially in the case when you have the requirement that the dependencies are too much. The queries still are strings, but you can index and search Java beans, which is really nice. It also supports sniffing. They call it node discovery, but it's basically the same as in transport and REST client. That's all I wanted to show you about the clients. There's one more thing I want to show you, which is Spring Data Elasticsearch. This is not really a client. This is more an abstraction on a higher level. It uses the Elasticsearch clients and provides a bit more around it, which can be a nice thing for people, especially for people starting with Elasticsearch, I would say. What is Spring Data? Who is using Spring Data already? A lot of the people. That's good because it's a really nice family of projects. What they are doing is they provide abstractions for different data stores, like for relational databases, for MongoDB, for Redis, I think, and a lot more. They don't try to pull everything in one module, but they make the specialty of the data store still available. The key value store has different characteristics than a document database, for example, and this is reflected in the project. Something which can be very impressive is the dynamic repository implementations we will see later. I think the most popular modules are Spring Data JPA and Spring Data MongoDB, which is a very, very nice pose of them. Of course, there's a module for Elasticsearch as well. This is built by the community as well, so this is not really done by the people behind the Spring framework, by some people outside, but it's still released with the Spring framework. How it works is that you annotate your Java classes with some attributes, like in this case, this is a special annotations for the Spring Data Elasticsearch, and you can tell it different stuff, like, for example, the index name it should use and some more characteristics. Then you can either... This is the simplest way to do it, like you can just add the ID annotation to one field, but you can also influence the other fields how they will be stored. So there's support for the analyzing process available as well. What you can then do is use this class you created to type an interface with it. So this is the... We just create an empty interface called dish repository in this case, because we want to search the food, and this extends the Elasticsearch crud repository, which is a special interface. There are more available in the project, but this is one you can use. So once you have done this, you can now just configure it. Of course, you can use Java config as well. It has its own namespace where you can, for example, just create an Elasticsearch client. So this will be a standard transport client, which is created here. It uses the Elasticsearch template for doing the basic operations, but the really important thing is this below here. This will scan our class path for any interfaces that inherit from one of the spring data interfaces. So this will automatically create implementations for these interfaces, so we don't have to write any code for accessing Elasticsearch. All of this will be done automatically. So in this case, we can again just create the Java bean and call this repository safe method, which is available automatically, and pass it one or more Java objects. And this will persist the data, index it, and afterwards we can of course search it again. These are the basic methods that are available on this crud interface, like you can just retrieve all of them or find one by ID. This is not very exciting for a search engine, like we want to have our query on our fields or on the text data. So what we can do with spring data Elasticsearch is just add more methods to this interface. So for example, we can add a method find by food, and just by using this naming convention, find by food, it will build an implementation that queries the field food parameter that is given here. So this makes a very nice language for querying your data, like you can have some stuff like find by a favorite price less than, which will then do a range query for the price and return all the dishes for you. So this is really nice if you don't want to get that deep into Elasticsearch and just want to do some basic queries. So there's also support for adding the query as a JSON string and you can even implement the methods yourself and do any custom logic you want to do. So that's the great thing about spring data. It's a high level abstraction. So it uses the existing client. It uses the transport client or something older, which is not recommended anymore. And there is a pull request for using Jest for accessing the data. So it might even be possible in the future to use the HTTP communication. And I think somebody might be working on the Rust client for Elasticsearch. You're using entity beans. The dynamic repositories are really, really nice. Yeah, the HTTP support is in the making. But to be honest, the project itself is not the fastest pace, unfortunately. So currently it's stuck on version 2.2 of Elasticsearch and a lot of features are missing. So if somebody is interested in providing a bit of development work for one of the spring data projects, this would be a very, very good case. Yeah, but for my impression, it's more for people who don't want to dig that deep in Elasticsearch. So normally you will use one of the clients instead. This is if you're using spring data already and I want to use it again. So that's all I have to talk about. We saw the transport client, which has the benefit of full API support. But you have to live with the Elasticsearch dependency. The Rust client that uses HTTP but is lacking in features right now. This will change. I'm sure this will be a very nice thing in the future. And there's Jest, which you can also use right now. It's a bit difficult what to recommend right now because of course once there is good support for the HTTP client in Elastic, maybe the Jest support will not be that good anymore. And the API is a bit different. So you might have to switch at one case. And there's spring data Elasticsearch, which is really more suited for people either starting with Elasticsearch or using spring data already and want to use it everywhere. Yeah, that's all I have there. Of course you can find, for the transport client and the Rust client, you can find a lot of information on the Elastic website, on the reference manual. Jest is on GitHub. It used to be by a company called Searchbox. I'm a bit concerned that this company doesn't exist anymore, but there's still development on the project. Spring data, another one. And all the example code is also on GitHub, on my account. And I will also publish like a transcript of this talk, like I wrote all of it down on my blog, so you can read all of it there again. So thank you again. I'm happy that my voice and the laptop voice finished. Are there any questions? About the concept of sniffing. So it allows your client to talk to multiple nodes in a cluster and not crash them with a crashed node. But what if a node is instantly crashed? Is there intelligence in the client to kind of shut it off from the pool of clusters? It differs a bit in the implementation of the different clients, but correct me if I'm wrong. For the transport client, for example, it will check every five seconds. It will do a special request on the Elasticsearch API. Elasticsearch has a monitoring API where you can retrieve the state of the current cluster. And it will use this for building the information which clients to access. So as a crashed node will not be in this cluster state, it will not be queried again. It might be queried once, I think, or even a bit more. But after a while, it should be fine again. I think it's five seconds it checks. In other clients, it's a few minutes, but you can configure it in all of them what happens. In the new REST client, there is some scoring with the connection fields. So it's going to apply like a pack of algorithm. Yeah, yeah. There is good functionality for this case. Yeah. Is there a concept of guided search, just like an Oracle Ndika? You actually add more filters and it narrows down the results. How do we achieve this kind of...  Yeah, you will use the aggregation feature. It can build these facets. And then you can add filter queries for refining the search result. So this is a very common feature to use. Yeah. And especially with larger datasets, this can be very beneficial for the user, because it helps them to find the right thing, because they might be... At first, they might not know what they are looking for, but later on they can see which facets are available and then just click on one and it's better. Yeah. Okay, if there are no more questions, you can also reach me with... You can ask any questions using email or Twitter or anything. I'm around here for a few minutes, I guess. Thank you.


phrasal verbs with break, which is correct. Tom, his girlfriend, last week. broke up, broke up with broke up from, broke it up broke up with two, that's a big problem. How will you break down, break down it break it down, break down on break it down three, the boss couldn't her busy schedule break away break it away break away for break away from break away from for, the teenager is acne breaking out breaking out of breaking out with breaking it out of breaking out with breaking it out. thehouse last weekend broke in, broke into was broke in, was broken into was broken into To learn more about this topic, see video at link. Or check out our websites for free English learning resources eslgole.com or


Today I will talk about prepos prints. I've presented myself before. I'm a graphic designer. I use free software and act and create my own prints to make perfect designs. Before we present what is prepos prints, I will contextualize where it comes from. Since years I've seen graphic designers using free software and also making their own and act software to experiment new shapes and have a new way to work. And when I talk about it, it's OSP, open source publishing that I already know here, are very inspiring by using free software and I don't use normally any common software to create graphic books like this program for the Baldami. We see enthusiasm from students, from school, like this diplomat from Grisdl, she experimented HTML and CSS to print to see different formats she can output from a website. And also there is some more experimental stuff like this one. It's called the PEGI machine by Sara Garza. It's an arcade machine where you can lay out with buttons and act on typeface, glitch images. And it's really like a gamification of making books. Also there is a lot of workshops from, I don't remember the creation, but maybe there is six workshops, five workshops, about their... It's Uchilebre Alternative, made by Rafael Bastiz, Sara Garza and Bashir Sousichial. They're making workshops. They provide one artist or designer using a specific tools and making three days, like a weekend, to create something. And they use pure data, blender, scribbles, but not in the common way, like making books with pure data, stuff like that. And in the same time Rafael is beginning to list projects made with Cessus prints for generative layout and alternative publishing tools. And in 2017, Sara Garza and Rafael Bastiz found pre-published prints and it's a rich group focusing on alternative and pre-publishing systems. And it's not a really defined group. We are a lot of graphic design collective and people are interested in that. We are friends also and we're beginning to... Yes, we group to talk about any question in this stuff. We've got... Since two years we've got plenty of actions, like workshops. This one is the first one of pre-published prints. It was a workshop with the collective of graphic design of Luzon. Also Sara Garza and Rafael Bastiz and they work with their students at Parsons School with the tools they create and they teach to their students. And for the example, Luzon uses the tool called Pad2Print. They act pad to the layout book collaboratively. And there is another workshop this last year about page media and page ES. It's a tool to make a workshop this afternoon and it's also... It's a pre-published print also. We can use HTML, CSS and JavaScript to export PDF on my books. We've got many meetings during this event like we regroup together and think about what we can do for future events or maybe what we can add in our documentation. I will talk about the wiki we have later. And every event we regroup together you can see the group move every time it's difficult to identify who participates in the group as quickly but it's kind of really good stuff. We make communication like we've got a fair at Getelier in Paris like there is some conferences and also some time when people can see the works and discuss with the designers more individually. There is another one in EnSat. It's a art school in Paris and it was made by Lucille Haut, Julie Blanc and me and we invite the other member of ProposPrint to talk to the EnSat students about what we can do with other software than InDesign or Adobe. We want to diffuse and promote this kind of graphic design process and we've got this wiki where you can see the event that we have already made. Maybe it's better than this. Is it correct? There is no T at the top? Oh no, it's an error. No. My bad. And you can see also resources and showcases show some projects that make this kind of complicated layout and also there is resources with tools and other websites that promote this kind of graphic design work to do. We've made a journal and it's completely made by HTML and CSS and in the journal there is some presentation of the member of the groups and articles about free type design and also how we can process the workflow of editing books with the free software and also web standard language. Our goal is to build a community and have a pedagogic action for inspired graphic design students and teachers and literature and promote an experimental creation system. Maybe I have some trouble with the vocabulary. But it's more about what we can do without the natural, the correctional tools in graphic design. But we identify with some problems because we have a lot of work separately and we are remaking that with other pedagogical ones and the week is quite empty for the moment because everybody is really occupied and we want to make simple the way you release the project and so forth. We write a manifesto about prepositions and it's really new and it's proposed to promote graphic objects and resources in line with the following characteristics. The object is crafted within an experimental process with alternative art or DIY tools made in a certain context constrained by its economy, its emergency or collaborative nature. The tool used to make the object and if it's possible the content of the object itself will be shared under a free software license. The object is documented on the website prepospin.org.org That is an entry in the database. And there is a mock-up for maybe the next website. It will be more simple. We will have all of things with creating projects and here we have five projects we really like for the months and it changes every month and every month we will try to put projects and in other parts you can submit projects there is a little formula with tags and you can add your project maybe something you find and participate to the database. I've got some goodies from prepospin if you want, some t-shirts, stickers and also I've got the journal if you want to take a look and overview. You can find more information here on Twitter and we've got a mailing list where you can ask us to members if you have something like asking for a workshop or maybe some information about that. That's all.


But also, for instance, just dancing. To me, dancing is also another form of release. When you dance really hard, you release all kinds of things. I am a massage therapist. I've seen people cry on the table when I am a massage therapist, because somehow, by touching certain muscles, who knows what, a lot of notions get released. So my confusion is we are trying to be not a body. Yet, a lot of releases still happen to the body, by the body, and the body. So I'm a little confused on that. I said, OK, I'm not a body, but then again, that's where sort of everything sort of kind of happens in quotes. So that's my confusion. Yeah, it's quite a mesmerism, because different points, Jesus talks about the body being nothing. And he actually says that in one of his workbook lessons, you will tell, if you have practiced well by this, the body should not feel at all. And so even this confusion around bodies having feelings, bodies having sensation, bodies having cellular memories that maybe get released through massage, or through different yoga practices, or maybe through circular breathing, rebirthing. There's so such a panorama of things. But basically, what it all comes down to is everything is mind. And there is nothing physical going on. And now we have quantum physics backing us up and saying that most of what we have believed as humans is very solid, is mostly space. Even down to the atomic level, most of an atom is just space. It's a tipensitini nucleus, and you've got these electrons whirling around it. And it gives the appearance of something that's like a building block. Like everyone was saying, you know, the world's made of atoms now, but all the material world's atom is the smallest one. But that's not true, either. It's mostly just space. So it's good to think of the world as kind of like a figment of imagination, in which, just like when you go to the movie theater, or Richard Pitt, IMAX theater, and it's maybe five or six stories tall, it can be very impressive. Or if you've come from the living as an aborigine or the jungle, I'm sure if you went to downtown Manhattan and you looked up at these skyscrapers, they would look to be enormous, even though we know that the galaxies are much, much bigger than anything that we have on this scale. But everything is mental. All sickness is mental. All experiences are mental. And so we have to go through an experience where we get that seems to be solid, retranslated back into saying that it's all mind. And that's why the basic idea of the course is ideas without their source. Christ has nevertheless the mind of God. And we could say the same as the projected world. It really has not left the mind of the perceiver. It's not like there's seven billion separate minds, because that's what the ego invented. But we could say just in terms of singular mind, the whole world has not left the mind of the perceiver. So you can go through experiences, and it seems like you can release tension through dancing. That's a common experience when you feel tight or massages is another good one. There's many, many things. And those are all the symbols. It seems like if you take ecstasy or if you take LSD or it seems like if you smoke marijuana and everything, it's also, there could be a sense of a loosening and a relaxation. But when you get to the cause-effect thing, you start to realize that just like drugs don't really induce relaxation, that's just a reflection of mind, that the mind is ready to be relaxed and it seems to be something that happens for a period of time, then the mind can go back to whatever its previous state was because there's still more unconscious beliefs. So I think if you just adopt an openness where you say, well, I'm not gonna try to pin the causation on any form. I'm not gonna try to avoid anything. Neither am I going to try to feel like there's anything that's my salvation in form. I'm just gonna practice being used as a miracle worker. And the more you do that, the sensations of the body that seem to be of the body and the appetites and everything all start to fade away because the mind tells the body what to feel. The body doesn't feel in and of itself. It kind of contradicts human experience, actually, because it's so strong. But then also mystical experiences contradict human experience because you're used to having kind of a limited, narrow perception of the world and then you have a mystical experience and suddenly it's so vast that you go, whoa, what was that? Or how do I get that back? Whatever that was, I want it back. And so you just come around to it. So I think it's just good to adopt a stance of just staying just completely wide open because the Holy Spirit can use anything. But just not taking the next step and just starting to interpret that because in the ultimate sense, even when I say release, that's still within the ego realm. It's still within the realm of consciousness. The Spirit doesn't release anything. But it's just the mind is going through this awakening experience seems to let go. And that's why we have all those great phrases, let go, let God. Elton John did a song one time, release, relax, let go. Hey now, discover your soul. That was a nice Elton John lyric. But that puts a little bit into a context. So hopefully that clears it up a little bit there.


Hi, I'm going to be demoing SecCop, a new security feature we're aiming to add to Docker containers. SecCop enables us to restrict certain system calls, preventing them from being used within containers. This allows us to add a new line of defense around the kernel to prevent container breakouts. I'm going to start by disabling SE Linux so you can see that it's actually me that is causing these changes. Next, we're going to run a dark container using a fairly standard command line, except we're going to add something new here. You can see here that we are going to have SecCop deny the NanoSleep system call, which is used in a few common commands, including sleep. And you can see here nothing appears to be different within the container. All appears to be well. So let's ask the container to sleep for a second. And you can see here we're getting operation not permitted off of the real-time clock. This is something that should never happen. This is not one of the normal error modes of that command. Now let's do this again without the SecCop command, and you can see it's sleeping, as you would expect. So this is just the most basic application of this. In a typical use-the-scenario, we would define a black list of system calls that would never be allowed to build containers, or alternatively a white list of the system calls that a container requires to run to allow it to use those and no others. Please note that the command line here that we're using is just a demo, and this is not a final version, nor is this actually in Docker at this point. This is still something that's making its way upstream. Thank you.