Amazon Web Services offers a way to connect to a MySQL or PostgreSQL database without having a password, instead an authentication token can be used.
Within AWS this type of authentication is called RDS IAM.
Users don’t need to store an username and password and credentials don’t need to be stored in the database, which makes this a secure authentication method.

So, this makes it interesting to use this in your Spring Boot application. Spring Boot will use a HikariCP connection pool by default, but HikariCP 4.0.3 doesn’t support the use of authentication tokens.

So, how do I make this work within my Spring Boot application?

More and more companies are switching over to cloud native environments. As a developer this gives me a lot of services to create awesome applications. The challenge that occurred to me right away was how to use all those new components during development, since some companies do not have a testing/development environment in their cloud provider to play with. LocalStack piqued my interest to simulate an AWS environment locally on my laptop, or when running the CI/CD pipeline.

This blog will give a brief introduction in what LocalStack can do and how you can use it for your own projects.

During my last year at JCore I was given the opportunity to do deep-dive in a self-chosen topic in the form of a 'Specialisation'. For this 1-year project I chose to dive deep into AWS how it works and how I, as a developer, make use of it. Some of the topics I covered during this were: DevOps, CI/CD and Security. As a demo and as use case I created a simple pubquiz application in which you can register and have a custom form for your answers. During the development of this application I faced different challenges that I had to overcome. This blog is about how I created a simple API that is exposed to the internet and how I tried to tackle the challenges of security, scalability and adaptability.

This post gives an example how to read values and secrets from an alternative store instead of storing them in config files, which is never a good idea. The example uses the AWS parameter store, but can be easily adapted to the newer AWS Secrets Manager or any other store!

The goal is to avoid configuration files like these:

Separating concerns is something we as developers are used to thinking about in terms of code. But the same also applies to identity management. If you’ve dabbled in AWS, you can get started right away with a root account. However, when it goes beyond dabbling, it might be a good idea to start splitting up responsibilities.

While I’m working with Terraform, I’d thought I’d share the way I set up my DNS for my Virtual Private Cloud (VPC).