It is trivial to downsize an AWS RDS instance. It is equally trivial to upsize AWS RDS volumes. However, to downsize AWS RDS volume you need to jump through lots of hoops.

So, why would you ever want to downsize an AWS RDS volume? One reason might be that you increased the volume size simply to get more burst credits for the volume. Then you did refactoring that reduced the need to have that many credits and want to save money. Or maybe you genuinely had a huge amount of data on your RDS instance volume, removed some of it but got stuck with a huge volume.

There are a myriad of ways to login to Linux systems using Azure AD credentials. Photo credit.

Introduction

There are several ways to do Linux Azure AD authentication. Note that Azure AD was renamed “Microsoft Entra ID” recently, but in this article we’ll use its old name, at least for now. In other words you can log in to your Linux hosts Azure Active Directory (“Azure AD”) credentials in various ways. Azure, Microsoft’s public Cloud, builds on top of Azure AD. In fact, your Azure users, groups, roles and role assignments are stored in Azure AD.

Introduction

This article tries to include everything you need to know about Keycloak Javascript policy deployment. By Javascript policies I mean authorization policies of Javascript type attached to Keycloak clients that have authorization enabled. If you don’t know what Keycloak authorization services are, you are probably in the wrong place.

While the process of creating and deploying the JAR files is pretty well documented, it is not altogether clear for the uninitiated how the policies are shown in Keycloak.

Introduction

Red Hat Openshift is essentially an opinionated Kubernetes distribution that comes with a large number of features such as CI/CD and container registry built-in; for a full list of differences look at the Red Hat OpenShift vs. Kubernetes. Openshift comes in a number of versions, some commercial and some open source. The naming history of Openshift is particularly confusing. That’s why I wrote this blog post where I attempt to list most Openshift versions and variants and outline their main differences.

Introduction

The Keycloak Authorization Services allows you to offload your application’s authorization decisions to Keycloak instead of implementing them in your code. This way you can leverage Keycloak’s advanced features like 2FA without any additional development on your part. If you’re unfamiliar with the Authorization Services I suggest having a look at the Keycloak authorization services terminology first. You may also be interested in our sample code for managing Keycloak authorization services programmatically. To be perfectly honest, there is no separate Keycloak authorization services REST API. While the authorization services do support the UMA Protection API, that API is only needed if you want your resource servers (e.g. webapps) to be able manage their own authorization services configuration inside Keycloak. For example, you might want to provide your webapp users the capability to grant access (e.g. read, write) to their own resources to other users. In this article we will not cover the Protection API at all.

Introduction

There’s no substitute for understanding what you’re doing, and that in turn is difficult without seeing what is happening. Debugging Keycloak OIDC problems without understanding what is happening under the hood is no exception to this rule. The purpose of this article is twofold:

1. Help you learn how Keycloak OIDC token exchange work

2. Provide you with the tools to debug Keycloak OIDC token exchanges in production environments

For the purposes of this blog post I’ve been using the OpenID Connect Playground application from the book Keycloak - Identity and Access Management for Modern Applications from Packt Publishing. I can recommend that book for anyone who needs to understand Keycloak and in particular the protocols it supports (OAuth2, OIDC and SAML 2.0).

Introduction

Keycloak Authorization Services are built on top of well-known standards such as the OAuth2 and User-Managed Access specifications (UMA). You can manage Keycloak Authorization Services programmatically, if needed, as described in our other blog post.

OAuth2 clients (such as front end applications) can obtain access tokens from the server using the token endpoint and use these tokens to access resources protected by a resource server (such as back end services).

In the same way, Keycloak Authorization Services provide extensions to OAuth2 to allow access tokens to be issued based on the processing of all policies associated with the resource(s) or scope(s) being requested. This means that resource servers can enforce access to their protected resources based on the permissions granted by the server and held by an access token. In Keycloak Authorization Services the access token with permissions is called a Requesting Party Token or RPT for short.

Let’s Encrypt on AWS can be a can of worms if you don’t know what you’re doing. Photo credit.

Introduction

Let’s Encrypt and the ACME protocol enable getting free (as in beer) TLS/SSL certificates. The main use for Let’s Encrypt is to enable HTTPS on web servers. Let’s Encrypt TLS certificates expire pretty quickly, in 3 months, but the idea is that renewal is automated so that you don’t ever really have to worry about expiration, unlike with commercial TLS certificates, which you typically need to manually renew every 12 months. Using Let’s Encrypt on AWS is in some cases a very viable option, but not so much in others. In many cases trying to use Let’s Encrypt certificates leads you down the path of Lovecraftian horrors and madness. Because “it all depends” I’ll try to explain when using Let’s Encrypt is viable in the AWS context and when you really should just give up an use certificates generated by the Amazon Certificate Manager (“ACM”) instead.

The symptoms

I recently received and email from Amazon Route53 asking me to verify the contact details for one of our registered DNS domains (replaced here with example.org). And sure enough, I saw wrong Route53 domain contact details in the email:

Subject: Confirm that contact information for example.org is correct.
Message body:

Dear AWS customer,

This message is a reminder to help you keep the contact information for your domain registration up to date. WHOIS records include the following information:

  Domains:
  example.org

  Registrant:
  Name: On behalf of example.org owner
  Organization Name: Identity Protection Service
  Address: PO Box 786
  City: Hayes
  State/Province: Middlesex
  Country: GB
  Postal Code: UB3 9TR

  Administrative Contact:
  Name: On behalf of example.org owner
  Organization Name: Identity Protection Service
  Address: PO Box 786
  City: Hayes
  State/Province: Middlesex
  Country: GB
  Postal Code: UB3 9TR
  Phone: +44.1483307527
  Fax: +44.1483304031
  Email: e793d865-97ab-42ab-805c-50cc36fd9202@identity-protect.org

  Technical Contact:
  Name: On behalf of example.org owner
  Organization Name: Identity Protection Service
  Address: PO Box 786
  City: Hayes
  State/Province: Middlesex
  Country: GB
  Postal Code: UB3 9TR
  Phone: +44.1483307527
  Fax: +44.1483304031
  Email: e793d865-97ab-42ab-805c-50cc36fd9202@identity-protect.org

The contact information provided above is what is shown in the public WHOIS. If your domain is privacy protected, the information will be different than the contact data you have submitted. To verify your contact information, please open the Amazon Route 53 console to view your current contact information and make any necessary corrections:
https://console.aws.amazon.com/route53/home#DomainDetail:example.org

If your information is accurate, you do not need to take any action.

Important
Under the terms of your registration agreement, providing false contact data can be grounds for the cancellation of your domain name registration.

Regards,
Amazon Route 53 

These wrong Route53 domain contact details originate from whois data for the registered domain. One might reasonably expect the whois data to match the contact details for AWS Route53 domain. However, in this case the Route 53 contact details were correct, but whois data seemed to be out of sync with those.

Introduction

Ansible has reasonably good support for managing various aspects of Keycloak. You can use the community.general.keycloak_realm module to handle realm management, including Keycloak realm SMTP server settings. However, in the true Ansible fashion the documentation looks good, but does not help you much. In fact, documentation only mentions that the smtp_server parameter is a dictionary, but that’s it. To be honest, that’s about as helpful as the description of the RealmRepresentation for Keycloak. This article aims to fill this documentation void. I also want to share some general advise for similar cases that pop up when you manage Keycloak programmatically.