About SRGTechnical articleRecruitment Information
About SRGTechnical articleRecruitment Information
HOME/Technical article/Verification of SSH using SSSD during Amazon Linux 2023 migration

Verification of SSH using SSSD during Amazon Linux 2023 migration

Suzuki from the Service Reliability Group (SRG) of the Media Management Division@sZma5a)is.
#SRGThe Service Reliability Group primarily provides comprehensive support for the infrastructure surrounding our media services, focusing on improving existing services, launching new ones, and contributing to open-source software (OSS).
This article is aboutCyberAgent Group SRE Advent Calendar 2025This is the first article of the series. It describes the technical verification process for implementing secure LDAPS authentication using SSSD and AWS services in conjunction with the migration to AL2023, and introduces the network configuration challenges and solutions encountered during that process.

Introduction

openssh-ldap

Target architecture

This OS upgrade was not merely a migration; one of its objectives was also to enhance security. Therefore, it was assumed that connections to the LDAP server would utilize encrypted LDAPS (LDAP over SSL/TLS). The outline of the architecture ultimately adopted is as follows:

Key points of the structure

The LDAP server will be located on a dedicated VPC, and each application running in a different VPC will connect to this LDAP server via AWS PrivateLink. All LDAP access from application VPCs will be aggregated via a Network Load Balancer (NLB), clearly defining the communication path and control point. Furthermore, TLS communication via LDAPS will be terminated on the NLB side, not on the LDAP server itself. Specifically, the client (SSSD on EC2) will connect to the NLB in the format ldaps://{domain}:636, the NLB will decrypt the TLS communication, and then forward the traffic to the backend LDAP server as plaintext LDAP (TCP/389).
The reasons for adopting this configuration are mainly the following three points:
  • Reducing operational burden:I want to avoid managing the certificates myself.
  • Limiting the scope of impact:It is sufficient if the communication path from the EC2 instance within the VPC to the NLB is protected by TLS.
  • Consideration for the existing environment:We wanted to avoid changing the settings on the existing LDAP server as much as possible.
 
 

Certificate Management

We decided to use AWS Certificate Manager (ACM) for certificate management. Using self-signed certificates raised concerns about high operational costs, such as distribution to each client and rotation due to certificate expiration. ACM offers three usage methods: public certificates issued by Amazon, private certificates using AWS Private CA, and certificates imported from external CAs. This time, prioritizing cost and ease of implementation, we chose the method of configuring public certificates in the NLB. This allows us to entrust certificate acquisition and renewal management to AWS.

Network configuration challenges and solutions

The most time-consuming part of this verification was the network configuration. In particular, the use of AWS PrivateLink (VPC Endpoint and Endpoint Service) meant that communication had to be permitted in multiple places via security groups, which made the configuration complex. Initially, we thought that simply configuring the security group between the client EC2 and the NLB would be enough to establish a connection, but that alone was not enough to establish communication. Ultimately, it was necessary to configure appropriate inbound and outbound settings in all of the following places.
 
In particular, we overlooked the inbound settings on the Interface VPC Endpoint side, which caused us to spend a lot of time troubleshooting connection errors. When using AWS PrivateLink, it's important to be aware that security group settings are required for all components along the communication path.

summary

This verification demonstrated that by centralizing TLS termination at the NLB and managing certificates with ACM, we were able to achieve LDAPS authentication in an Amazon Linux 2023 environment while minimizing operational burden and requiring minimal changes to the existing LDAP server configuration.
Furthermore, it was a good opportunity to deepen our understanding of network components such as VPC peering and AWS PrivateLink, and to reaffirm the importance of security group design in environments involving multiple VPCs and multiple services.
SRG is looking for new team members.
If you are interested, please contact us here.