I have a spring boot app deployed to Swisscom App Cloud that should to be secured with mTLS.
Obviously there's spring security... Specific to Swisscom App Cloud I read about securing traffic on https://docs.developer.swisscom.com/adminguide/securing-traffic.html.
It is unclear to me how the two play together...
If I enable mTLS via spring security, would that work as is or would I need additional configuration for the Swisscom App Cloud? (I came across HTTP routing which mentions passing client certificates for mTLS https://docs.developer.swisscom.com/concepts/http-routing.html)
Is the configuration of mTLS on Swisscom App Cloud a replacement for what I would otherwise enable with spring security or would I still need to configure something within my application?
Securing traffic mentions deployment manifest and BOSH manifest, is the latter (and maybe additional) configuration needed to enable mTLS on Swisscom App Cloud (i.e. would I need to have access to configs besides the deployment manifest) ?
Update
My use case that I have a REST API that will be consumed by a client outside of Swisscom App Cloud. It was decided that it shall be secured using mTLS.
The admin guide you're referring to is meant for platform operators (i.e. Swisscom), so it's not a resource that can be leveraged by end users.
What is your use case? If it's only a security requirement to check off a list, be aware that the platform itself will be using mTLS internally soon, so the whole path up until the app container is secured. That might be enough for your auditor.
If you really need to validate client certificates by yourself, CF's way of doing so is leveraging X-Forwarded-Client-Cert (https://docs.cloudfoundry.org/concepts/http-routing.html#-forward-client-certificate-to-applications).
However, we've currently not enabled this (there was no need for it up until now), but we can do so.
Update:
According to this explanation, insertion of X-Forwarded-Client-Cert is actually done transparently by the platform. So if you add the client application's certificate to the server application's truststore, it will verify the client certificate.
Update 2:
As you can see in the discussions below, it looks like there is currently conceptually no easy way to allow apps to do proper mTLS using X-Forwarded-Client-Cert. The only option currently is using tcp routes, which is something you can request with your Appcloud support team.
Related
I have a spring boot application which runs on Azure Kubernetes Service and it exposes a private IP, using this IP I have configured this API on Azure API Manager. All the traffic will be coming to this spring boot application via API manager. Client to APIM connection is secured with SSL certificate coming from azure API manager. But from API manager to back end API application is not secured it is plain http. Is there any security issues for this architecture?
For your situation, since you already use SSL certificate to protect your APIM, I think the architecture is no problem even though there isn't any security configuration between APIM and backend api. APIM will not expose your backend, so others can't get your backend IP or backend url according to the APIM. So I think you do not need to add any other security configuration for your architecture.
For the comment about Azure AD mentioned by Tiny, you can also use Azure AD to protect your api or APIM, but I think it is unnecessary.
is possible create authorization server for PKCE authentication in current version of spring security?
I did research and I found out this authorization server project https://github.com/spring-projects-experimental/spring-authorization-server but there is no usable sample for that project.
I also find out that spring recommends Keycloak as authorization server, but it is not fit for my case.
We need be able fetch and verify user against remote service, and then use authorization server only for generating and verifying jwt tokens. In my knowledge Keycloak should holds also users right? So the best solution would be custom spring standalone authorization server. Is it possible in some way? Thank you!
You may have a look to this project: CloudFoundry User Account and Authentication (UAA) Server.
UAA is a (Spring MVC) component of Cloud Foundry but it could be used as a stand alone OAuth2 server. It can support external authentication service. And there is a Pull Request that implements PKCE: https://github.com/cloudfoundry/uaa/pull/939 (not yet merged, but under review).
You can find an example on how to use UAA on baeldung.com.
As far as I know, Spring framework has one more implementation of the authorization server. It is a part of spring-security-oauth project. But this project was moved into maintenance mode.
According to this migration guide, the new authorization server project (that you have already found) will be created to change the legacy solution.
From my point of view now there are several possible options:
Using old legacy spring-security-oauth. More examples with old auth server
Using external services like Keycloak, Auth0, Okta and etc
I'm learning about using SSL Certificates with Spring Boot. Specially using Let's Encrypt ones.
They have the limitation of being expired after 3 months, so they should be renewed and as far as I know, when renewing the certificate we need to restart the Spring Boot app in order to make it load the new one instead.
Some time ago, I was playing around with Eureka and Zuul Gateway, to develop microservices... And I recall I also set a git repo to be used as a Spring Cloud Config. I do not remember well, I think we can use Spring Cloud Config without using the microservice arch.
So my question is: Can we use this Spring Cloud Config mechanism that reload properties to reload the SSL Certificate? The idea would be to trigger the properties reloading mechanism, and as the ssl is configured via those properties, I think maybe it can be reloaded.
I'm planning on automating the process of getting and renewing the Let's Encrypt certificate and avoid the downtime on my app.
Best regards!
SSL certs are applied at the JVM level - neither Spring Boot nor Spring Cloud Config has any control over this, and so to apply a new cert would require a restart of the JVM instance your app runs in, because you've updated your keystore. Being able to dynamically add certs without shutting down the JVM would be a major security flaw.
In the AWS ecosystem, the idea is that if you ever shut down your VM, you lose that VM, and the contents on it are gone forever. With Spring Cloud (Config, Zuul, Eureka) you can spin up VMs that get registered with Eureka via Config, and Zuul uses the info in Eureka to do the load balancing. So, the way it should be done is you spin up another VM with your Spring Boot instance with the updated cert, and kill off the older VM which evaporates thanks to AWS, and Zuul takes care of the dirty work of being a "reverse web proxy", routing the requests to the new web server as required.
The can of worms you open going this route is that now you have to implement 4 servers and a VPN to support them, your Zuul server becomes the target of external web requests, and you might need to look into the "circuit breaker" pattern on how to handle HTTP request failures - Hystrix is the next thing to look into.
With Digital Ocean, I'm not sure what you might have to do differently, but a JVM restart is unavoidable.
Actually, it depends. Certificates are applied on SSLContext level and SSLContext can be refreshed during runtime. It is completely possible to update the certificate in KeyStore and refresh the SSLContext, moreover, Tomcat has a special helper function reloadSslHostConfigs that helps you to do that.
So what you ask is completely doable:
Spring Cloud triggers certificate update event notification or via polling
Your application loads updated certificate either from Spring-Cloud or from some shared storage
Your application issues reloadSslHostConfigs, so that Tomcat updates its SSLContext
For implementation details of the certificate reloading, you can take a look at the letsencrypt-helper library. It allows generating and keeping-up fresh your LetsEncrypt certificate without JVM restart.
I'm pretty much new to spring cloud gateway. I have configured routing with two different apps with 'path'. Now, I need some help/docs on
1. How to route to different instance of an app from spring cloud gateway?
2. How to enable sticky session?
My apps are not using spring boot/eureka. I do see that I can use lb://service-name if i'm using any discovery client (unfortunately that is not my case).
Thanks in advance.
IMHO:
How to route to different instance of an app from spring cloud gateway?
Routing to different instances is the basic job of what spring cloud gateway is doing. Spring cloud gateway implements the pattern named client side routing along with the ease of service discovery. So if you are not using any discovery server or your apps are not registered with any discovery server, you loose the dynamic discovery and routing feature, BUT still you can specify your server list (refer to Netflix Ribbon). Until then you can think about your routing strategy.
How to enable sticky session?
I suppose that's one requirement of your routing strategy - implement sticky session because you are not using shared session store. According to my limited knowledge of spring cloud gateway, sticky seems not being supported out of box. But it could be customized with a Filter, see shipped LoadBalancerClientFilter for reference.
Good luck!
I am learning building microservices using spring boot, Spring Cloud(netflix OSS Components). I have used netflix Eureka for service discovery, zuul for api gateway, ribbon, feign while running in my local machine.
Netflix eureka, zuul, ribbon, feign spring cloud config are not useful when we deploy to PCF?(if yes what are the alternatives available in pcf and how to configure them?)
As who are building microservices follows CI/CD approach, how developer verify working of their micro services before pushing code as we don't use eureka, zuul,ribbon,feign in production pcf. (how to simulate pcf environment in developer machine?).
I'd suggest to read below content before implementing if you have any doubt regarding usage of Eureka and Zuul, you will get all answers yourself.
https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance
https://github.com/Netflix/zuul/wiki
As who are building microservices follows CI/CD approach, how developer verify working of their micro services before pushing code as we don't use eureka, zuul,ribbon,feign in production pcf.
Answer to this question is: You must be aware of JUnit test cases, so you can run you test cases using deployment pipelines to make sure all your functionalities are working as expected or you can use Test Automation for the same.
(how to simulate pcf environment in developer machine?).
Answer to this one:
You can use eclipse plugin you are using eclipse/STS IDE. Or you can connect all PCF services from you local machine using CloudFactory
#Bean
public Cloud cloud() {
return new CloudFactory().getCloud();
}
https://docs.pivotal.io/pivotalcf/2-1/buildpacks/java/sts.html
Here are some thoughts:
Eureka Service discovery: in my opinion this is not strictly necessary when running on PCF. When you push an app on PCF usually a route is assigned to your app, and you can use this Route as a poor man's service discovery. Eureka would allow you to use client-side load balancing in the case of container-to-container networking, but usually you wouldn't need this.
Zuul: Can be very useful also on CloudFoundry in case you are doing things like writing frontend-for-backend services, providing frontends for different devices (mobiles, desktops, i-pads) that use the same backend services. Might also be useful for an authentication/authorization layer or rate-limiting. One native CloudFoundry alternative would be to use route-services for tasks such as rate limiting, authentication/authorization.
spring-cloud-config: makes sense if you want your configuration to be under version control for different environments. This is useful no matter if you are running on CloudFoundry or not. I don't know of any alternatives on plain CloudFoundry.
spring-cloud-feign: makes sense if you want use annotations such as #RequestMapping with your Feign client interfaces. This is independent on if you are running on CloudFoundry or not. AFAIK there are no alternatives for this in case you want to use Spring MVC annotations with Feign.
ribbon: makes sense if you want to use client side load balancing as opposed to let the CloudFoundry router to do the load balancing for you.
How developers can check locally if this works for them:
In general, I don't believe developers should need to check locally if their app is working fine together with zuul, cloud-config-service, and eureka.
They could check this in a dev or test space or environment though.
If they really want to check this on their local machine, they could download PCFDev and run these infrastructure components there.
Hope this helps.