 OK, so I randomly proposed yesterday that we should have a Birds of a Feather session on security. My background is security and I keep on seeing slides with security sprinkled all over them. So I wanted to kind of open the conversation and actually work out what people are doing in this space. So the concept of a Birds of a Feather session, if you're not familiar with it, is an open conversation. It's not me standing here spouting things, talking about things. It's about sharing ideas. It's about collaboration. And so what I propose to do, how many people have used agile coffee as a way of working? One, OK. We're going to introduce the rest of you to it. So to make sure that it's not just me talking about things, what I would like you to do is to propose topics, ultimately. Just very brief conversations. Write up on a post-it note what you'd like to talk about. Are there any burning questions that you have within your organisation? Why did you actually come here? Is actually a great question or a great topic? Is it compliance? Are you being told to add security? Are you looking for understanding about security features and the like? So in the next five minutes, if you just write topics on these post-it notes, we'll put it up on the board. And then everyone gets probably one vote each. And we can go through, prioritise which topics people are most interested in. And then whoever proposed that topic can just outline it and we can have a discussion about that. Does that make sense? The guy who did agile coffee before says that makes perfect sense. So at least I got the description right. So please stand up, write post-it notes, vote on topics. If this isn't what you're expecting, then there are other great sessions. I'm not going to lock the doors and force you to be in here, okay? Absolutely. And if you want to listen to a particular conversation, remember to vote on it. And that's where we absolutely will, okay? Just as well I got post-it notes. Yeah, that would be awesome. Menomalistic material. Pardon? Menomalistic material. Menomalistic preparation. You can only suggest one topic. No, you can suggest it and maybe each one. Is there any more pens? Okay. Those people don't run off with my pens. There's more pens here. I think people have less, some spare pens. I think we needed to run down and get them. Okay. So if you just put them up there. Anyone else for a pen? I thought I said security go to hell. Okay, so if we finish up writing up the topics now, I think we've got a fair few. So if everyone who just wants to listen can come up and actually read them, vote on them, which ones we want to talk about. How would you want people to do as many dots as they want or just restrict them? Just restrict to, because of the number, probably about one dot each. If you're really passionate, I might let you have two. So as a preview, we have build packs. Should we manage them in-house? Running docker images in Diego. Rooting between containers. Isolation, tenant services, hardening of CF, boundaries in services. So that's kind of a bit of container security. Over here, build packs, strong authentication, application security, not just authentication, but also authorization. So up there as well. Security staging groups for application in regards to build packs and what to do to connect to a DB. So build packs over here. Isolation. What security testing is done before, done for open source cloud foundry and what testing do operators need to do? So probably a testing. Malware protection as a service for apps. Why is Clamab be the only one? So probably services. Security group help. That's got a bit of angst behind it. How to guess traditional security teams engaged in cloud foundry, hardening of CF. Okay, run through. Which one do you want to talk about? Pass back the pens. Please don't walk off with them. So it looks like in record time of under 10 minutes we've gone from having absolutely nothing to wanting to talk about rooting between containers. Actually how? So we have rooting between containers, container security, strong authentication. Is that one? Key topics for application security, isolation of tenants, deployment security, and how to get traditional security teams engaged. So very much the focus of feedback is rooting between containers, strong authentication, container security, these top three, and then we'll get on to those. So we have about 20 minutes. So could I invite the person who was wanting to talk about rooting between containers to just introduce the topic and any particular pain points you have? So who wrote that up? My name is Seerah Khantana. I work for Audi Business Innovation. So it's a shy company for Audi 80. So it's just an idea came up that we're using right now as a container, a lot of them to provide a service for applications. You can buy a service with applications and like it is more very concerned about that, about for us that how can we secure more from one container to another one and so there's something like that. So to kind of play it back so I just make sure I understand the situation. So you have services, are these third party services that you're bringing in like databases? Yes. And they are within containers? Yes. And some application like is divided to one services and this application one services would like to talk with another services and like we have one application for one team and another team and it is like between we would like to like share and to make something like that. So is that one container talking to another as in a different application? Who has the experience of this kind of problem that's been explained? Do you want to contribute what you found? We do a lot of stuff in Spring that's been cloud and so we use, typically when we use your address service discovery and that gives us ribbon, myU container. Sorry, thanks. That gives us ribbon to client-side load balancing across those things. The caveat in Cloud Foundry is you have to allow container to container but in our ecosystem we use UAA to do token-based authentication. And so we also are still ensuring that any service call between applications is actually authorized. So from our perspective we've basically created an internal set of microservices that are allowed to connect to each other. They're all registered with UAA. They all do token-based authentication when they make those calls and those calls happen through RU. So I'm not sure that answers any questions. Questions? That means that if you talk from one container to another container so you have probably a UAA client prevention token which you use to get tokens and set the tokens to that other container but communication-wise you take the full ROM that means you go to your whatever Lothan answer and then Cloud Foundry router and the Cloud Foundry routers then what you need to communicate with them. So you can do that. Do you override your default settings to do that? In our case we still go through the Go Router but we don't actually go out to the like through DNS. So it's not quite a full trick. So to open this conversation up to people who are maybe less familiar with Cloud Foundry one of the things around routing between containers or between applications is that you have to go out of the application through the NAS into the Go Router and then back into the system by default. There is a way that you can open up your entire environment to allow any app to talk to any other app but generally that is frowned on particularly from a security context so that going via the top is the way to do it today. Now in terms of what Chip was saying yesterday when he was presenting the roadmap is they are looking at ways of going directly within it to avoid having to go via the Go Router. I mean we talked about authentication authorization as being a key part of this. The other part is in terms of confidentiality. Now I saw on some slides yesterday that in terms of traffic going into Cloud Foundry you of course have TLS to the Go Router now in 2007 but within the system itself between the applications or from the Go Router to the particular container traditionally that is an IPsec tunnel. Pivotal has had that if you are paying them for support you can get it that way but I saw yesterday that I think SAP and there might be some people from SAP here have released IPsec tunnel link that again further enhances these container to container communications. Any final comments before we move on to strong authentication and so the question is do isolation segments help in any way? I have an opinion does anyone else? So I think isolation segments help from getting an architecture or an infrastructure certified because it means that you can take your applications and say even if it is compromised there isn't any crossover because there's an individual virtual machine and you get a whole set of extra security controls around that within infrastructure as a service and VM based security architectures there is a long history of how you provide that security to the extent that regulations like PCI DSS can really help in the special interest groups from finance on Monday they were actually talking about how separating out the log files separating out the execution environments will help people run PCI DSS workloads on cloud foundry because you have that isolation and that separation which is what people what the standards demand Does that make sense? I think it certainly helps if you're doing calls within the same segment that's a trusted segment Okay, so who proposed strong authentication and who has experience of strong authentication are you ready to come up? Good, hi, my name is Mathenia Bwyr, I'm working for SAP and we have demand for strong authentication so what we did for the CF command line interface is handling strong authentication using a SAML identity provider that works pretty well but there's also need for strong authentication within the cloud foundry components for instance if I have a service broker then the cloud controller is talking to the service broker and that is one connection we can currently only authenticate with basic authentication using a password and therefore what we'd love to have is support for strong authentication also for these server-to-server connections within cloud foundry Okay, who's from Pivotal and can take that and try and put it on the backlog? I guess with SAP your access is at the highest level anyway so I'm sure it's already there Yeah, I mean strong authentication usually we see this as something we have a digital signature there for instance X59 client certificates we consider a strong authentication two-factor authentication when it's user when it's user interactive but for server-to-server communication I would see it as X59 client certificates for instance So I guess I should have asked this question right to the start How many people here are security people doing cloud foundry 3, 4 How many people are cloud foundry people doing security the other way around a few more What are the rest of you guys doing? Application developers worried about security Okay, good share Okay I have some opinion on the strong authentication from source broker perspective if we want to implement this we need change broker API and we need to hard like it has to be very very complicated to do a doll-out I think it's certification for example I try certificates for example we need much stronger and it's yeah it's from someone on the top but I don't think we have lots of I mean in pure I think we have lots of ideas how to implement different possible security but it just different ways it needs someone from community to propose Okay, we need these certificates to add to service broker then we can work from it because service broker it might be not deployment in sometimes and it's like we need to customize CFR to add these certificates and talk from CFR maybe I mean what we have for what we have for instance is an application which is acting as a service broker and we're not yet on the ego that means anything we put on Cloud Foundry is more or less public and that means currently without the strong authentication anyone can just start guessing on a password from outside get the user's log this is one of the things we need to address as I said service broker it needs to go on high level it has to be great proposal because it's set up point we need to change I mean if you would move to each 5 line certificates say ok Cloud Controller has capability of sending a client certificate as part of the TLS handshake and it's a job of the service broker to do the authentication it's not as hard as I said it just sound bigger but ok so this sounds like a perfect topic to go and see Abby about because I've used championing the service broker API and I think as we are focusing on that particular topic I think that would be a great person to go and see and if you need an introduction I can point to if you would like to have that ok perfect so thank you we've got about 10 minutes left so we seem to be making good time container security this one who who wrote that up I'm Zohar Gertz I also work for SAP and the topic also has been pretty much handled with first topic we had with the container to container communication so that was what my intention when I wrote that down was more like container security is a container trusting other containers or not and how can it secure calls or make sure that calls container are those calls which are supposed to go in and not any calls which are not supposed to go in but I think that has been already pretty much handled ok cool so one thing that I would add around this one of the key things that if you talk to the guys who raise the hand of security people doing cloud boundary is compensating controls so there may not be a perfect solution to that authentication guarantee that A goes or is connected into B but there may be other things like logging, audit controls those kind of things where you can detect when something out of normal is happening but interesting that container security is such a hot topic here ok moving on how do we get traditional security teams engaged with CF deployments who raised that and I'm sure this is thought about across pretty much everyone in the in the room so good topic hi Stuart from Kingfisher not for being in sorry do I need you to play our boundary we're just deploying playing around with it at the moment really we stood up some environments and we asked our security team who do a lot of things to pentest it because that's a good thing to do and they went away and they said yeah we've got guys who can do that no problem and then they pentested it and they came back about half an hour later and said yeah that's all good we've done that and I was like that was quick what have you actually done we sat down with them and what they had done was they had out of scope kind of found it because they didn't know anything about it so essentially they pentested them and then we asked the load balancer well done boys that was worth the money so we then sat down with the security team and said right guy you can't do that because this is going to be public facing we need to do something useful with it please and they said okay that's great here's an enormous spreadsheet we're doing to fill in answer all of these questions and then we'll talk again and they don't even know most of the questions on that spreadsheet are from the traditional enterprise IT security focus and aren't relevant to well I ask well loan powers so it's really a case of what everybody done about engaging with their existing security teams and how do you get them up to speed to even understand what's relevant what's not relevant that's it really because otherwise I haven't got a clue and we don't really know what to do to get them to have a clue so thoughts, feedback surely everyone here or many people have come up to this perfect reason I have some experience so it kind of started with me sort of drawing a diagram that showed them what Cloud Foundry was and to explain to them what sort of things we were going to deploy and kind of the risks I thought we were going to encounter along the way and then there was like a few different conversations really about what things they were most worried about and what things would take them a while to get their heads around and as a result of that we de-scoped some stuff from our project pushed it back a little bit because that was going to take longer for them to get their heads around so we got to push out our platform we changed our roadmap in a way that didn't really didn't really significantly hold up what we were trying to do and like basically just trying to explain what we're trying to do and what the next phase is so it's like so did you basically get more of their team and stick them in your Cloud Foundry squad team whatever it is and go right, you're with us you're our security expert help us for six months because that's what we're thinking about doing just stealing one of them something like that he came in from another organisation that was more security minded he did three days a week for like two months two or three months and like I think that was really good reassurance that someone who they trusted had actually been in there and recognised that we were actually thinking about the right stuff and like knocking ideas off talking about things not just saying that's the thing we'll do later it can't do that that's not an option so we have a couple of minutes left sorry I'd just like to add into this conversation as well my background has been security architectures and doing these kind of things a couple of different things that you have to watch out for in Cloud Foundry the first one is overzealous security people when they suddenly start getting educated about the go routries versus Cloud Controller and all those things they start trying to apply policies within Cloud Foundry so saying oh can I put a firewall rule here between this Diego brain and that hang on hold back so education is essential but too much education can cause issues and you've got to hold back from it in terms of the way that or two things that I've heard from the foundation heard from pivotal themselves the first one is when you think about Cloud Foundry think of it as black box appliance and secure around it is the first start of it security accreditors and certifiers want to understand threats what is it the problem that could cause issues within this it's not just attacking for confidentiality denial of service all those kind of things so what are they concerned about the second part is then when you actually find a threat how can you fix it and one of the great things about Cloud Foundry and the huge value things is that you can patch at all the different levels and do the redeployees and all that so when you explain that to security okay this is a good thing that we've never had before and that can open a very fruitful line of conversation so I think this is a massive topic that we should all continue to discuss we're coming up to about 20 pass so I don't want to keep you from your lunch how many people are on Slack or the Cloud Foundry Slack channels there's a very good security one in there what I propose to do is take all of these we didn't have nearly enough time to cover them put them into that Slack channel as the topics and then we can actually start discussing them as a community answering questions for each others does that work for people I've got GDS SAP good stuff well thank you for participating when I looked at the schedule just before this session and there were I think 10 people turned up and walked in here I did think I was in the wrong room so very cool that so many people are interested both from the application side and the security side and then also the platform deployment enjoy lunch and thank you