Forem: DoiT International

Preconfigured Nexus Repository Manager (NXRM) Docker container

Meir Gabay — Thu, 10 Jun 2021 10:48:31 +0000

TL;DR: Link To Project @ GitHub - unfor19/nexus-ops

Recently, I've been looking for a way to avoid hitting DockerHub rate limits. One of the solutions that I came up with was deploying Nexus Repository Manager OSS (NXRM) as part of my CI/CD environment, so the CI/CD runners hit NXRM instead of DockerHub when attempting to pull public Docker images.

As always, I Googled a lot on how to get started with NXRM, and it seemed like it's best just to run it locally and see how it goes.

Ladies and gents, I give you my hands-on experience with provisioning a preconfigured NXRM Docker container.

The Goal

NXRM Docker container that is preconfigured with DockerHub and AWS ECR Public Gallery. Here's what I found in Google:

My Issue With Existing Solutions

I want to run the init-script immediately when NXRM is ready and part of the NXRM startup. I don't want to execute any script manually on my machine; everything should be done as part of NXRM's startup process. Most existing solutions describe running something on your machine that will communicate with NXRM; I'm looking for something different.

Desired Outcome

Let's break it into a few bullet points that will describe the desired output.

The init-script is readable and easy to maintain.
Restarting the NXRM container should be idempotent; the init-script should not attempt to create existing resources.
The init-script should be written in a popular scripting language, like Bash (so I chose Bash).
Automated actions should be done using NXRM REST API, to support adding more features easily. Since I chose Bash, I'm using curl to make HTTP requests.

Designing The Init Script

The desired outcome is clear; now, I need to declare the actions that the init-script will perform when starting the NXRM container. Here's the list of actions (in order):

Changes the initial random password that is in /nexus-data/admin.password to admin
Enables anonymous access - allows anonymous users to access localhost:8081 with READ permissions
Adds Docker Bearer Token Realm - allows anonymous pulls from local Nexus registry localhost:8081
Creates two Docker repository of type proxy
1. docker-hub - DockerHub
2. docker-ecrpublic - AWS ECR Public
Creates a Docker repository of type group
1. docker-group - The above Docker repositories are members of this Docker group

Creating A Custom Docker Image

I've created a Docker image based on NXRM official Docker image.

Here's is how the Dockerfile looks like:


ARG NEXUS_VERSION="3.30.1"

FROM sonatype/nexus3:${NEXUS_VERSION} as app
USER root
RUN curl -L -o /usr/local/bin/jq https://github.com/stedolan/jq/releases/download/jq-1.6/jq-linux64 && \
    chmod +x /usr/local/bin/jq

USER nexus
ENV NEXUS_DATA_PATH="/nexus-data" \
    NEXUS_ADMIN_USERNAME="admin" \
    NEXUS_ADMIN_PASSWORD="admin" \
    NEXUS_API_PATH="service/rest/v1" \
    NEXUS_BASE_PATH="http://localhost:8081" \
    NEXUS_OPS_VERBOSE="false"
WORKDIR /"${NEXUS_DATA_PATH}/nexus-ops/"
COPY provision/ .
CMD /nexus-data/nexus-ops/entrypoint.sh

Note: I added jq to the mix because I intend to use more APIs, and I'll need to analyze some JSON data. I find it best to analyze JSON data with jq when using Bash.

As you can see from the Dockerfile above, I'm copying the directory provision/ to the NXRM image, and instead of running /opt/sonatype/start-nexus-repository-manager.sh as the CMD, I wrapped it with the provision/entrypoint.sh script.

Bottom line, the whole logic is maintained in the init-script called entrypoint.sh.

Here's how the main function looks like

main(){
    start_nexus
    set_global_variables
    wait_for_healthy_response
    set_credentials
    change_initial_password
    enable_anonymous_access
    realms_enable_docker_token
    repositories_create_repository_wrapper "proxy" "docker-hub" "${_NEXUS_OPS_PATH}/repositories/docker-proxy-dockerhub.json"
    repositories_create_repository_wrapper "proxy" "docker-ecrpublic" "${_NEXUS_OPS_PATH}/repositories/docker-proxy-ecrpublic.json"
    repositories_create_repository_wrapper "group" "docker-group" "${_NEXUS_OPS_PATH}/repositories/docker-group.json"
    log_msg "Finished executing - ${_NEXUS_OPS_PATH}/entrypoint.sh"
}

Final Result

Here's my project @ GitHub - unfor19/nexus-ops. To understand how it all works, check the provision/entrypoint.sh file; I tried to make it as neat as possible.

One more thing; you'll find the directory provision/repositories in my project. That directory contains the JSON structure of the provisioned repositories. As an example, here's the command for creating the DockerHub repository

repositories_create_repository_wrapper "proxy" "docker-hub" "${_NEXUS_OPS_PATH}/repositories/docker-proxy-dockerhub.json"

Final Words

Initially, I was slightly intimidated by NXRM; it seemed complex to proxy Docker requests via NXRM. However, after creating this project, I think I got the idea, and I hope you did too.

AWS Security Groups - Once And For All

Meir Gabay — Wed, 02 Jun 2021 19:03:59 +0000

As part of securing applications in the cloud, it's important to set the proper network rules, for maximum security and to minimize collateral damage.

Here's a quote from the official HIPAA requirement for Transmission Security.

A covered entity must implement technical security measures that guard against unauthorized access to e-PHI that is being transmitted over an electronic network.

HIPAA

For those of you who are not familiar with HIPAA, it's a very strict regulation that requires protecting medical records and other personal health information (PHI).

Most startup companies that develop a product for the medical-healthcare sector, aspire to become HIPAA compliant.

Here's the question you need to ask yourself when it comes to Transmission Security

What security measures are currently used to protect e-PHI during
transmission? HIPAA - Security Rule - Technical Safeguards

Network Security Layers Overview

I'd have to write a book to cover all the network security layers, so let's get a quick glance at the most common network security layers in AWS.

Application - AWS Web Application Firewall (WAF)
Subnet - AWS Network Access Lists (NACLs)
(Virtual) Firewall - AWS Security Groups
Network - AWS Network Firewall

In this blog post, I'll focus on the Virtual Firewall layer. In AWS, the implementation of a Virtual Firewall is done with AWS Security Groups.

Stateful Vs. Stateless

Security groups are stateful, the official docs, describe it as follows:

If you send a request from your instance, the response traffic for that request is allowed to flow in regardless of inbound security group rules. Responses to allowed inbound traffic are allowed to flow out, regardless of outbound rules.

By default, a security group is created without any inbound rules. That means it doesn't accept traffic from any device that attempts to initiate a connection.

The default outbound rule is 0.0.0.0/0 which allows devices to initiate connections to anywhere. Once a connection is initiated, the security group rule is ignored.

So what is stateless? We'll cover that in the Blocking Specific IPs section.

Security Groups Ground Rules

Once a connection is initiated, the security group rules are ignored and traffic is allowed for the new connection.
There's no way to enforce security group rules on existing connections. Rules are applied to new connections only, so you must terminate existing connections, to force new security group rules.

Practical Example

Let's say you want to SSH from your local machine to an EC2 instance, that has a public IP address.

To achieve that, you'll add an inbound security rule that allows SSH connections from My IP (your IP). And then, you'll SSH to the EC2 and it'll work as expected.

Here comes the tricky part; What would happen if, during your SSH session, someone removes your inbound security group rule? Nothing. As mentioned earlier, security group rules apply to new connections only, since your SSH session is active, you can still continue with your work. If by any chance, you get disconnected for even a split second, the new security group rules will take place and you'll get disconnected.

Allow Or Deny?

This is very confusing; One might want to deny traffic from a known set of IP addresses. It is common to think that Security Groups can be used to block traffic explicitly, though it is impossible.

Security Groups are designed to Allow access from/to sources, and implicitly block unknown sources. When you add a security group rule, you don't have an option to set its type (Allow/Deny), it is Allowed by design.

Blocking Specific IPs

To address the need for explicitly blocking specific sources, you can use AWS Network Access Lists (NACLs), which are stateless, and as part of setting a Network Access Rule, you'll have the option to set its type (Allow/Deny). It's important to mention that NACLs operate at the Subnet level, while Security Groups operate at the VPC level.

Reminding you that NACLs are stateless, which means you'll need to create a rule for both inbound and outbound for any source/target device. Unlike Security Groups, if you haven't explicitly allowed a connection both inbound/outbound, it is denied by default. The default NACLs rules, for both inbound and outbound, are All traffic, from/to: 0.0.0.0/0.

NOTE: I rarely use NACLs, unless there's a specific need to block a set of IP addresses at the subnet's level, which in my experience, is quite rare and should be used with cautious.

Allow Access According To IP and Request URI-Path

One might think "but hey, I want to allow access to https://myapp.com/admin/dashboard from my IP only, how can I do that? Since HTTP requests are handled at the application layer, you can use the AWS Web Application Firewall.

Create a rule for web request component settings with the required URI Path
Create a set of IPs and add your IP, call this set whitelisted.
Create another rule that whitelists your IP address.

Here's the pseudo-code of the set of rules that should be created

if AND(
URI-Path == https://myapp.com/admin/dashboard,
SourceIP != Whitelisted-IPs
)
then Block

Selecting The Right Defense

Security Groups are designed to Allow traffic from/to sources, at the VPC level.
NACLs can be used for blocking a set of IP addresses (bots, bad reputation, etc.) at the Subnet level.
AWS WAF can be used for blocking all traffic to a specific URI-Path, and allowing traffic only from a specific set of IP addresses (whitelisted).

References

Final Words

When I first started my journey with AWS, Security Groups were one of the first components that I encountered. I also didn't have any background with networks, so stateless and stateful didn't mean anything to me. Once I broke it down and found out which service should be used for each purpose, it was all clear.