How to Use the Open Ziti Zero-Trust SDK with Spring-boot
As security becomes increasingly more important application developers will need to adapt to the changing environment. Not many zero-trust providers incorporate the developer perspective into their products. However, NetFoundry is unique in that it offers an app embedded solution for zero-trust applications that require private connectivity.
WHY DO I CARE?
Applications hosted on the public internet are susceptible to attacks and it well known that Java has been widespread adaptation across the internet. This post is for Java developers who are interested in zero-trust and work with spring-boot. Open ziti, NetFoundry’s open source zero-trust SDK, allows spring-boot developers to embed zero-trust into their applications.
There are three types of service hosting. Each layer of hosting increases the level of security. As shown in the figure above, native SDK service hosting is the most secure way to host a service. The SDK isolates the application from the host on which it is running. This protects the client from ransomware and malware. Once the application has been established as zero-trust endpoint on the network then it doesn’t matter what the device is running. This is powerful and secure.
WHAT DO I NEED?
Adding ziti to an application is easy. Anyone with an introductory level knowledge of Java and familiarity with web services can do this.
HOW DO I DO IT?
The first step is to visit open ziti overview. Here we will find all of the documentation on ziti, it’s components, and how it is used within the confines of zero-trust. To get started sign up for a free account at here.
CREATING A NETWORK
The top level of the NetFoundry hierarchy is an organization. Sign into your console. Then click the blue button with a plus sign (+)
from the left side of the administration panel. For our example we will use, spring-boot-net.
The network creation step performs a set of api calls which are managed by NetFoundry’s MOP (Management Orchestration Platform). These api calls stand up a network controller in a hyperscaler i.e. Azure, GCP, AWS. A controller will be provisioned. The controller is the brains of the NetFoundry network.
It handles the certificate store for the identity of endpoints. It also handles authentication when an identity tries to connect to a network, and posture checks. It’s analogous to an SD-WAN, SD-WAN uses a controller, as well.
CREATING AN EDGE ROUTER
The preferred edge router hosting type NETFOUNDRY HOSTED. Edger routers are similar to MPLS routers. In MPLS providers have edge routers, as well. In the MPLS world edge routers take a customers traffic and put it into their network. In the case of a NetFoundry, they perform the onboarding and offboarding of endpoints to the NetFoundry fabric. As a user you can choose where you want the edge router to be. For example, we provision an edge router in major cloud providers such as AWS, GCP, Azure, and OCI. In our case we will use us-east-1 Ashburn.
CREATING AN EDGE ROUTER POLICY
This is used to separate users using your network. For example, users in group A shouldn’t be able to access resources from group B. The diagram below shows how edge router policies restrict access to services.
CREATING AN ENDPOINT
Now that we have an edge router we need to create an edge router policy. We’ll name this edge router “public” and assign it the attribute #all. As the world progress towards ABAC (attribute based access control). NetFoundry stands out from other ZT providers in the simplify the administration of network resources via attributes. Any endpoint with this attribute we’ll be able to access all of the routers with the same attribute.
CREATING A SERVICE
Now that we have our edge router, endpoints, and edge router policy we’ll create a service. For example, this service would allow clients to access the spring.demo service. We’ll give the service the default attribute #all.
CREATING AN APPWAN
Next we will add an AppWan with the same service attribute from our service and endpoint attribute from our newly created endpoint.
SETTING UP OUR SERVICES
After you created your endpoint you should have downloaded your endpoint registration token (the file extension is .jwt). After completing this step visit how to enroll an identity. Then move the binaries to
/usr/local/bin (make sure the binaries are executable). Then you’ll want to run
ziti edge enroll \
--jwt my_file.jwt \
clone down the ziti-sdk-jvm sample. Then update the
application.properties file with the path to your identity file and the service name, i.e. spring-boot. Then run
../../gradlew bootRun to start the service.
It is recommended that you use the
gradlew that ships with both of the repositories. There could be version issues with running a different
gradle binary. If you encounter
Failed to parse keystore this means that the
application.properties file was not configured properly. Ensure that you are not using quotes. An example configuration is shown below
ziti.id = /Users/evangertis/development/ziti-sdk-jvm/samples/ziti-spring-boot/spring_boot_12_29.jsonziti.serviceName = spring-boot
Another common issue is not having attributes properly configured. Review the screenshots shown above to make sure your attributes match what is shown.
Congratulations on configuring you first open ziti service. Please share what you learned at ziti.dev.
The Edge Router is the entry point for Ziti-based clients. It is responsible for authenticating incoming connections by…
ziti-sdk-jvm/ziti-springboot at main · openziti/ziti-sdk-jvm
This component allows to Zitify a spring boot application. Project goals: make spring boot service available directly…