2015-10-20 by Axel Fontaine
At its core, CloudCaptain analyses the payload you pass it (like a .jar or .war file) and generates a minimal immutable image for it. This image contains two main parts: a disk image and metadata.
The metadata is what interests us here. It is built as part of the analysis phase and contains information about your app, such as the ports and the healthcheck urls it requires. If you use Spring Boot or Dropwizard this info can even be automatically extracted for you from these frameworks' native configuration files.
CloudCaptain then later uses this metadata when running instances of your images to correctly provision infrastructure. In the case of AWS, CloudCaptain will use the port and healthcheck info to automatically set up and configure Elastic Load Balancers, Security Groups and more.
However so far, unless you explicitly configured a custom security group, any port you have opened was always open to the world:
While this is great for publicly facing parts of the service like http(s) ports it may not always be what you want for other parts of it like the admin interface for example.
Today we are introducing a new CloudCaptain feature called Restricted Ports. What this allows you, is to further constrain the access rights of a specific port down to a specific range of ip addresses.
We have added
support for fixed addresses like 12.34.56.78
as well as
CIDR blocks such as 12.34.56.00/24
(granting access to all ip addresses between 12.34.56.00
and 12.34.56.255
).
Additionally we have also added support for a special address denoted by @
, which refers to the
current public ip of your local workstation. This is particularly useful when working with protocols which lack
authentication such as JVMTI for debugging. You can now open a debug port that is only accessible from your own
IP address.
If your ISP assigns you dynamic addresses you can combine these approaches and grant access to the CIDR block
of your current IP such as @/22
.
This is how this then works out in practice if you want to for example restrict the access of the admin port of your app to the current ip of your workstation:
Another feature we added is support for UDP as not every service needs the additional features
(and overhead) of TCP. To achieve this you can simply add /udp
to the port definition:
> boxfuse run -ports.myudpsrvc=6543/udp
This will then effectively expose UDP port 6543 to the world. This is of course combinable with the restricted ports described above.
While certain protocols or interfaces aren't meant to be publicly available, yet are an important part of
your application, we have introduced Restricted Ports to make it easy to constrain access
to a single address or a CIDR block. We have also added support for the convenience value @
to easily
refer to the current public ip address of your workstation. On top of that it is now possible to also open UDP ports.
Here is for reference the complete list of currently supported syntax variants for port definition:
80 | TCP port 80, universally accessible |
80/tcp | TCP port 80, universally accessible |
80/udp | UDP port 80, universally accessible |
80/tcp:@ | TCP port 80 only accessible from your own IP |
80/udp:@/20 | UDP port 80 only accessible from the IPs in the CIDR /20 block of your own IP |
80/udp:1.2.3.4 | UDP port 80 only accessible from 1.2.3.4 |
80/tcp:1.2.3.4/31 | TCP port 80 only accessible from the IPs in the CIDR /31 block of 1.2.3.4 |
Have fun and keep on deploying JVM applications to AWS with ease and pleasure!
And if you haven't already, sign up for your CloudCaptain account now. All you need is a GitHub user and you'll be up and running in no time. The CloudCaptain free plan aligns perfectly with the AWS free tier, so you can deploy your JVM application to EC2 completely free.