|
Starting today, package repository administrators can manage the configuration of multiple packages in one place with the new AWS CodeArtifact package group configuration capability. A package group allows you to define how packages are updated by internal developers or from upstream repositories. You can now allow or block internal developers from publishing packages, or allow or block upstream updates for a group of packages.
CodeArtifact is a fully managed package repository service that makes it easy for organizations to securely store and share software packages used for application development. You can use CodeArtifact with popular build tools and package managers such as NuGet, Maven, Gradle, npm, yarn, pip, twine, and Swift Package Manager.
CodeArtifact supports importing packages on demand from public repositories such as npmjs.com, maven.org, and pypi.org. This allows your organization’s developers to retrieve all of their packages from a single source of truth: your CodeArtifact repository.
Simple applications routinely include dozens of packages. Large enterprise applications can have hundreds of dependencies. These packages help developers speed up the development and testing process by providing code that solves common programming challenges such as network access, cryptographic functions, or data format manipulation. These packages may be produced by other teams in your organization or maintained by third parties, such as open source projects.
To minimize the risks of supply chain attacks, some organizations manually check the packages that are available in internal repositories and the developers who are authorized to update those packages. There are three ways to update packages in a repository. Selected developers in your organization can push package updates. This is usually the case for your organization’s internal packages. Packages can also be imported from upstream repositories. The upstream repository can be another CodeArtifact repository, such as a company-wide source of approved packages or an external public repository that offers popular open source packages.
Here is a diagram showing the different options for exposing packages to your developers.
When managing a repository, it is crucial to define how packages can be downloaded and updated. Allowing installation of packages or updates from external upstream repositories exposes your organization to typosquatting or dependency confusion attacks, for example. Imagine a bad actor releasing a malicious version of a well-known package under a slightly different name. For example, instead of coffee-scripta malicious package is cofee-script, with only one “f.” When your repository is configured to allow fetching from upstream external repositories, all it takes is a distracted developer working late into the night to write npm install cofee-script instead npm install coffee-script to inject malicious code into your systems.
CodeArtifact defines three permissions for three possible package update methods. Administrators can allow or block installations and updates that come from internal publish commands, from an internal upstream repository or from an external upstream repository.
Until now, repository administrators had to manage these important security settings on a package-by-package basis. With today’s update, repository administrators can define these three security parameters for a group of packages at once. Packages are identified by type, namespace, and name. This new capability works at the domain level, not the repository level. Allows administrators to enforce a policy for a group of packages across all repositories in their domain. They do not need to maintain configuration of package origin controls in each repository.
Let’s see how it works in detail
Imagine that I manage an internal package repository using CodeArtifact and I want to distribute only versions of the AWS SDK for Python, also known as boto3, that have been verified by my organization.
I go to the CodeArtifact page in the AWS Management Console and create python-aws a repository that will serve verified packages to internal developers.
This creates a test repository in addition to the repository I created. External packages from pypi it will first be placed in pypi-store internal repository, where I will check them before serving them python-aws repository. This is where my developers will link to download them.
By default, when a developer authenticates against CodeArtifact and logs in pip install boto3CodeArtifact downloads packages from the public pypi repository, sets them to pypi-storeand copies them further python-aws.
Now imagine I want to block CodeArtifact from fetching package updates from an upstream external pypi repository. I want to python-aws only serve packages that I have approved from my own pypi-store internal repository.
With the new capability we released today, I can now apply this configuration to a group of packages. I go to my domain and select Package groups tab. Then I choose Create a package group button.
I enter Package group definition. This expression defines which packages are included in this group. Packages are identified using a combination of three components: a package format, an optional namespace, and a name.
Here are some example patterns you can use for each of the allowed combinations:
- All package formats: /*
- Specific package format: /npm/*
- Package format and namespace prefix: /maven/com.amazon~
- Package format and namespace: /npm/aws-amplify/*
- Package format, namespace and name prefix: /npm/aws-amplify/ui~
- Package format, namespace and name: /maven/org.apache.logging.log4j/log4j-core$
I invite you to read the documentation to find out all the possibilities.
In my example, there is no concept of a namespace for Python packages, and I want the group to include all packages whose names start with boto3 comes from pypi. Therefore, I write /pypi//boto3~.
Next, I define the security parameters for my package group. In this example, I don’t want my organization’s developers to release updates. I also don’t want CodeArtifact to fetch new versions from external upstream repositories. I only want to approve package updates from my internal test directory.
I cancel everything Inherits from parent group boxes. by choosing Block for Publish and External upstream. I’m leaving Allow on Internal upstream. Then I choose Create a package group.
Once defined, developers cannot install different versions of packages than those authorized in the python-aws repository. When I, as a developer, try to install another version of the program boto3 package, I get an error message. This is expected since it is a newer version boto3 the package is not available in the upstream staging repo, but there is block a rule that prevents packages or package updates from being fetched from external upstream repositories.
Similarly, let’s imagine that your administrator wants to protect your organization from dependency replacement attacks. All of your internal Python package names start with your company name (mycompany). Admin wants to block developers for accidentally downloading s pypi.org packages starting with mycompany.
An administrator creates a rule with a pattern /pypi//mycompany~ with publish=allow, external upstream=blockand internal upstream=block. With this configuration, internal developers or your CI/CD pipeline can publish these packages, but CodeArtifact will not import packages from pypi.org which begin with mycompanysuch as mycompany.foo or mycompany.bar. This prevents dependency replacement attacks for these packages.
Bundle groups are available in all AWS Regions where CodeArtifact is available, at no additional cost. It helps you better control how packages and package updates land in your internal repositories. It helps prevent various supply chain attacks, such as typographical issues or dependency confusion. That’s one additional configuration you can add to your Infrastructure as Code (IaC) tools today to create and manage your CodeArtifact repositories.
Go ahead and configure your first batch of packages today.