 Hello, all together. It's time for next talk. I hope you're all active still after a lot of information. My topic is managing distributed secrets in applications on Cloud Foundry with Spring Cloud Vault, quite a long name. You can find the presentation and all demos I'm giving today also on GitHub already, so just in case you want to look at the presentation afterwards. I bought a lot of slides, but I will skip some of these because this is a one-hour talk. In fact, I will more concentrate on giving some demos what is what about To my person I'm coming from Stuttgart Germany, some consultancy company. We also support you in developing cloud native applications, mainly in Java using Cloud Foundry. I'm a frequent speaker at lots of conferences, like I was at a spring IO this year in Barcelona. I'm also an OVASP member, so that's why I'm so keen on security. So there were a lot of talks talking about authentication, authorization with OpenID Connect, like the last talk here. So we are pretty good at that stuff doing authentication well and authorization well for APIs so far. But what about our sensitive data? So that's sometimes in a weak point in our applications. Also seen by the OVASP, the OpenWeb application and security project organization. Just a short hands. Who knows the OVASP top 10 already? A lot of people. So towards the end of the year, we can expect a new version of that. So in fact, they declined the release candidate one at a moment, so they reworking it completely again towards the end of the year. But the point A6 sensitive data exposure is still in the current one. What makes it even more important to our applications is the new general data protection regulation coming in the European Union. I think it will be there in May next year. So everybody has to follow that. They mentioned their privacy by design for our applications and breach notifications for applications. So it is expected that our applications have privacy designed into the application already. From the beginning, not putting it in the application at the end as we do it sometimes currently, but our applications should deal with sensitive data and protect the sensitive data of all people. And also have a clue if there is a breach so that we can notify the people that are affected by that breach. So that becomes even more important. So what is typical sensitive data? You can think of passwords, service credentials like DB passwords, something like messaging credentials, even our two client secret stuff. For this, we also need some kind of secret credentials. Then we have encryption keys of all kinds, credit card numbers, social security numbers. The list can be more and more. I think all people that develop with Spring Boot knows lots of these application property files, application YAML files. You probably also have seen database credentials in clear text into that application properties. That's what I see each day in the projects. Even I noticed some production passwords in such property files. So some developers have always to have it a comfortable way. So they sometimes use the same password for productive and development stages, which is very serious. We want to get rid of that. So that's a sample as we see it very often in the wild. So my super secret password. And even if you secure your passwords with some encryption, you have the chicken egg problem again. Because what to do with the key you need for encrypting that stuff. So you need to encrypt the key again for that first encryption and then it goes on and on. So several problems we have to deal each time in our projects. So today I want to talk a bit about some security evolution there. It starts by using Spring Boot as I mentioned here with the application properties. Then you have the Spring Cloud project. It gets a bit better with Spring Cloud config server already because that supports encryption as a service out of the box. But even there you have the problem still with where to store the encryption key. Either you have the private public asymmetric stuff or you have the symmetric key to store. Next step would be to bring together a Spring Cloud with the world project. I will give a short introduction to Walt. And the final stage is to bring the Spring Cloud Walt together and put it also into the Cloud Foundry Cloud. So what is Walt? Walt is implemented by a company HashiCorp. I think you all know WakeRent for example or a console of that company. So they also build Walt. It's an open source. You can have it as an open source but you can also have it as an enterprise edition with some more features and support for that. Especially if you have to roll it out into your big enterprise company with high availability features and stuff like that you may go to the enterprise edition as well. So Walt is a tool for all kinds of secrets to manage. So Walt can deal with tokens, can deal with passwords, can even create SSL certificates for your local CA. Automatically can deal with API keys, DB credentials and lots of other secrets you can imagine. So the Walt lead at HashiCorp names it as a security Swiss army knife. So that's even more suitable here in Switzerland now. So most people think of Walt as a simple key value security store but it's much more than just that. So you have the key features, the secure secret storage as I mentioned. You have the ability to create dynamic secrets. That's very important for database credential rotating for example. So it does some similar things as the mentioned Grad Hub tool we have in Cloud Foundry. You also have the data encryption inside that Walt that uses a secure EES cipher. And you also have automatically leasing renewal and revocation features. So all your secrets have some lease time. You can configure so they are automatically invalidated at some stage. You have also some supporting features like authentication for Walt. So you can authenticate via several providers for that. You have a fine grade authorization so not everybody can access all the secrets in Walt. So you have a really fine grained ACL feature so that every administrator for example can only see some part of the Walt storage. So if you have an insider attack for example that insider can only attack some small piece of Walt not the complete storage. It also has audit lock so if somebody wants to attack it's all in the lock. So the other admin recognized that at a sudden that somebody else wants to attack something so they can just shut down the Walt to get knowledge of that person that wants to attack that before something serious happens. And you also have the high availability mode for that stuff. So the main architecture of Walt is some small executable. You just have to download the executable and can just run it out of the box. If you want higher availability for example then you can run it with console. Then you have some some authentication features that you can use. You have some different storage back ends, some different types where you store your secret data. And you have some secret back ends or some mechanism what secrets you can store. And you have that audit back end for that logging stuff. And Walt incorporates some trust boundaries so it does not trust the client and it also does not try to trust our storage back ends. So if you store it into some for example MySQL so that's an untrusted data thing for Walt. So Walt never gives the encryption keys or stuff like that to the back end database. Regarding the Walt storage we have lots of possibilities. You can store it in MySQL in Google Cloud, Platform Services, Amazon Web Services, Postgres. You even have some plugin mechanism which is quite new to Walt. So you can even store it to more proprietary stuff like Oracle databases and there's more to come. But you can also store it for testing purposes which I'm demonstrating right now using the file system or in memory. So you also have possibilities for different kind of secrets. So you can generate PQA certificates out of the box for local CI stuff. You have a transit back end for providing encryption as a service, a key value store for just storing key value secrets. You can also generate your keys for SSH terminals automatically. You can also then generate credentials automatically for MongoDB with rotation for example. So there's lots of possibilities there as well. And for authentication you also have several possibilities. You can just use simple username password stuff, use a token, you can use LDAP, multi-factor authentication is possible. Also Google Cloud Platform or Amazon API key. But even you can use mutual TLS and also Kubernetes or you can use GitHub accounts for authentication. So one more security thing Walt implements is that not one administrator can open Walt initially. So if you start up Walt, it is initially sealed. So you have to unseal Walt first and there we have the concept of key shares. So you always need several keys to unlock Walt. So no admin should have all the keys. So at least you should need two or three administrators so that you can initially open the Walt for operation. So that's another security like for example if you wanted to launch a bad example is a Tom bomb, then you also need several persons to initiate that launch. So that's kind of the same approach here. So it's demo time. I want to show some smaller. So as I've mentioned Walt is just a simple executable. You can download it from Walt project. So if you want to start Walt, it's quite simple. So there's also a development mode which I'm already also using for the demo today. It's a bit shorter. You don't have to do all that key share unsealing for that. So that's a bit simpler mode for that. So you just start Walt with the dev command. Then you have Walt in place. So what Walt gives you is... So in the dev development mode it just generates one unsealed key and it's automatically unsealed already. And you get a root token for authentication. So that root token will be important for us to authenticate actually to Walt. Then you have to give information to the Walt client mode where the Walt server has been started. And then you can just operate with Walt or just get the status of the Walt. So it's not sealed. We have one key share for example and now you have to authenticate to Walt. So in fact that that token authentication is also only suitable for demo purposes. So for serious production you should use AVS API or LDAP or something more serious. What I want to do now is create some a bit simpler token that I can remember. I give it just a name so that's also a token I can authenticate because I've pre-configured my demo applications that I have for that token. So that's a bit simpler. So now Walt is operational. You can also look what is inside Walt already. So Walt works with some mounts of backends as I mentioned. So we have two backends now. We have the copy hole and the secret backends. The system backend is just for internal stuff of Walt. So the secret is the key value store you have. The secret key value store operates with that authorization stuff with ACL. So depending on the user you cannot access all trees of the Walt. And the copy hole is much more simpler. So the copy hole is just bound to the token you are authenticating. So there's no ACL with that. You can just store some token. Everybody who has that token can read that token again. So just mounting another backend is quite easy. So for example for encryption as a service you need that transit backend. You just mount it and then you have a new path for just accessing also that encryption as a service which my next demo application will be using. So now with that in place we are all ready to go for the next step. The next step would be to use it actually with spring. So there are in fact two projects of spring. So you can use it without cloud config server actually with just using the spring Walt project. Or you can use it with the cloud config server. So the initial demo will show how it is used with spring Walt. Spring Walt just provides you a Walt template. So those that are familiar already with spring know the gdbc template or two templates stuff like that. Now you have a new template called Walt template. So you can do most of the operations with the Walt template against the Walt. And you also have abstract Walt configuration that configures the connection to the Walt for you in spring. So we have also some demo for that. So for that demo I used that encryption as a service stuff of Walt. As you can see here this is the encrypt sensible data is just encrypting two attributes of that person like a credit card number and a social security number. I'm using Walt so you get that Walt operations from the Walt template. And then you can just call the opt for transit. You have to use a key name which I'm creating on starting the application automatically. And then you encrypt it without actually knowing the key. So it's just a symbolic name to reference the key of Walt inside. Then the other part is to decrypt again that stuff and I'm just calling it in the corresponding operations like for example to find all methods. I just decrypt on the fly all the sensible data to show it to the user on the UI. And also in saving I'm encrypting that stuff. So in starting the life demos are always a bit dangerous as we learn the keynote. So I just call a rest API that I've put above that service just decrypting the numbers. As you can see it's automatically decrypted again. I also have some other API that use the encrypted version of that stuff. As you can see now you see the encrypted values as you directly get from the database. So Walt puts in some namespace in front of that to know with which version of the API Walt encrypted that. So he knows which version to decrypt it again. Also I'm using some in memory database for that stuff. So you can also see that it's really encrypted there. As you can see we have the credit card number encrypted and also that social security number encrypted and I just decrypted it on the fly using the Walt as being Walt project. So that's the first stage to use encryption as a service in your application. So there's no, you can use it very easily so you can encrypt all that sensible data, sensitive data you have in your applications. And I think most of our applications nowadays have some sensitive data that are due to data privacy stuff. So that was the encryption as a service. You can also use spring cloud config. There are two types you can use it. You can use spring cloud config directly. So if you use spring cloud config directly, spring cloud Walt directly as I name it. Then you directly have some kind of config server that points to a Walt server. And you can just encrypt all your properties out of the box with Walt. And all your application properties are automatically mapped into that secret key value store for you. So it's mapped automatically in your application namespace. So if you call your application, for example application one, then it's stored into secret slash application one namespace automatically for you. So you can also rotate your database credential with Walt that way. So you just have to give that Walt configuration the name of your spring data source property which is that preconfigured one of spring boot. And then it automatically puts in the decrypted value when running the application. So it's something similar to the Grad Hub. And there's a second approach to use Walt with spring config server. With that you have the possibility to still use your not sensitive data in a Git repository. But additionally use your sensitive data to be put in the Walt. So you can choose which property goes into Walt, which property goes into the Git repository. What you have to configure for that is just activate a second profile, spring profile just to the existing Git one which is the default so far. You just have to activate the Walt profile in addition and then you get also support for Walt. Then you have to configure the addresses for the Walt server and you're good to go. That's the next one. I also have some small demo for that. First I have to stop the old one here. So I have a spring cloud config server and a spring cloud config client prepared for that. Hopefully that works as well. So now I should have, yes. So I also have some small rest client for displaying my properties. So at the moment I only have that not sensitive property stored in my Git repository. So that Git repository is shown here. On GitHub I have just a small Git repository with just that property inside that is read by the config server and returned to my client. The second one is not returned so far because I did not have stored it in Walt already. So it's not inside Walt. But we can change that quite quickly. If we just write that into that namespace involved of my application which is called config client in that case. How was it named? I'll just name it test for example. So if I refresh it's not displayed so far. If you use the spring cloud config server you know that you can have an automatic refresh. If you post to some special address. I just post to that local host 8080 refresh endpoint. And then it should automatically be refreshed without restarting the server. That's always the thing with the should always write it the correct way then it should work. You have to refresh again. I think it's late today. Finally I got it right. So as you can see it now decrypted automatically from the vault in spring cloud config server. So you can have both worlds into one. You can have the non-sensitive data in the git repositories and store the sensitive data in Walt by using the same spring cloud config server. The last slide I wanted to show was that you can also have it inside cloud foundry with the vault stuff. There's a vault service broker official one by hashy corp you can use and there's also a new project spring cloud vault connector. That does that auto configuration with spring boot stuff. I did not bring a demo because that's just in milestone status and I have expected it to be finished this week. But the spring guys are a bit late this week. So spring boot has some delays came out just today I think. And also that spring vault stuff was a bit delayed. So unfortunately I could not show a real demo of that stuff. So we are at the end of the session. Some question for the spring cloud config server or for your own application that wants to use a wall template. In a real world scenario would you have to give some token so that the vault server knows which ACL to apply. Yes you have to give a token to authenticate your application to Walt. Where is this token then stored? That token is stored in the bootstrap. But as I mentioned before just giving a token is a bad example for doing it in production. There are several other ways to authenticate with Walt. There's a pretty good documentation that documents all that lots of authentication possibilities. You have mutual TLS you have AWS possibilities to authenticate. So there's no need to put the clear text token inside your property. With spring five and web flux on the doorstep. So encryption and decryption and transition is a blocking operation. Is there also plans to have a reactive driver for the world? I think so because spring security also is just in the way implementing reactive support for all that security stuff. So I think according to that also spring vault will have some in place. They're also developing currently the spring vault two versions which are in milestone three. So it's quite early stage so I cannot say how far they are with reactive stuff. Thanks. Oh the last row. So I have used spring cloud config server a lot recently and a lot of the encryption and decryption of the properties can be done out of the box using spring cloud config server itself. If you have a symmetric or symmetric encryption you can do that with the config server itself and it can do properties encryption and decryption on the fly. So I'm just failing to bit understand where should I use vault in this case because if you know there are encrypt and decrypt URIs available out of the box from config server. Yes. If you provide the asymmetric and symmetric keys within the server you could make sure if the encryption or decryption would be handled by the server or by the client itself. So I just want to know why should I go for vault and in which particular case then I would have to go because right now the config server solves most of the problems. That's a good question. The main advantage of using vaults with spring cloud config is that you with spring cloud config you have also to administer your keys for encryption decryption. So then you have the next problem with chicken egg problem you have to put the key somewhere in clear text. You also have to decrypt that key again. The advantage of vault is that it never exports some kind of key so you never get hand on the encryption key. And you have the possibility to authenticate with several methods and you also have the possibility to have an audit log and have ACL. All that you don't have with the spring config server out of the box so you have more control. So it's a bit more secure than the spring cloud config server. So if you want to to hide mostly 100 percent secure then you have to use hardware modules for security but they are quite expensive sometimes. Thank you. One last question then we run out of time. You were talking about this in the context of GDPR but there's more to GDPR than just protecting data. There's also storing the consent and the permission to do with a piece of data which also has to be stored in a protected way. Are you doing any complete GDPR solutions or are you just handling encryption with this story. I'm not sure if I got your question right. Well there's more to GDPR than just encrypting the data. You're right. It's just only a small part small part that I just prefer to hear. And I wanted other bits of it will probably involve encryption like storing the consent that is given for the use of data and storing the purpose. Yes. So the first step is to do not start them at all. So that's the best approach to start at the least amount of data that is required. But that small amount of data that is required should be stored as secure as possible. Yes encrypted. So I wondered whether you were doing a higher level GDPR solution in addition to just covering the encryption side of it. There's lots of organizational stuff in addition to the technical stuff so far. But that rules in that protection regulation is also as always very unclear formulated as I name it. So privacy by design can be anything. Okay so if there are any further questions I round for by until the end of the day so thank you.