Skip to content

Commit

Permalink
update readme
Browse files Browse the repository at this point in the history
  • Loading branch information
AlisonB319 committed Nov 8, 2024
1 parent ccbd1ea commit b120bd7
Show file tree
Hide file tree
Showing 2 changed files with 73 additions and 3 deletions.
74 changes: 72 additions & 2 deletions vulnerability-reporting-vms/README.md
Original file line number Diff line number Diff line change
@@ -1,3 +1,73 @@
# AgentBaker Vulnerability Reporting VMs
## Goal
In order to catch newly discovered CVE's, we want to be more proactive than relying on trivy during our VHD build process. The goal of craeting vulnerability reporting is to create a set of VMs duirng our VHD release build that will be running Az-Sec-Pack

In order to catch newly discovered CVE's, we want to be more proactive than relying on trivy during our VHD build process. The goal of creating these vulnerability-reporting-vms is to create a set of VMs duirng our VHD release build that will be running our production VHD images and AzSecPack

## Implementation

This is a go program that takes a directory of vhd-publishing-info.json files in order to create VMs from the *captured_sig_resource_id*. Here is an example vhd-publishing-info.json

```json
{
"vhd_url": "https://vhdbuildereastustest.blob.core.windows.net/vhd/1.1730016408.31319.vhd",
"captured_sig_resource_id": "/subscriptions/8ecadfc9-d1a3-4ea4-b844-0d9f87e4d7c8/resourceGroups/aksvhdtestbuildrg/providers/Microsoft.Compute/galleries/PackerSigGalleryEastUS/images/AzureLinuxV2gen2/versions/1.1730016408.31319",
"os_name": "Linux",
"sku_name": "V2gen2",
"offer_name": "AzureLinux",
"hyperv_generation": "V2",
"image_architecture": "x64",
"image_version": "0.0.1",
"replication_inverse": "2",
"publisher_base_image_version": "2.20241006.01",
"publisher_base_image_sku": "cbl-mariner-2-gen2"
}
```

from the json, we need the `image_architecture` in order to choose the proper VM SKU and `captured_sig_resource_id` to use as the VMs image.

Before craeting a VM, we must ensure that these azure resources also exist. They will be created before VM creation -

1. resource group
2. vnet
3. subnet
4. network interface

One VM will be created for every vhd-publishing-info.json file passed.

## ADO pipeline

While it is possible to run the go code locally, the intended use case is for it to run after the build / e2e tests in our *AKS Linux VHD Build* pipeline. After the build step completes, vhd-publishing-info.json files are published in two seperate artifacts

```
artifacts
|---azurelinuxv2-gen1 // using this path
| |--vhd-publishing-info.json
| |--other-azurelinuxv2-gen1-files
|
|---publishing-info-azurelinuxv2-gen1
| |--vhd-publishing-info.json
```
these vhd-publishing-info.json files are identical. There have been consolidation efforts to put all sku specific files under an artifact of just their name (ex - azurelinuxv2-gen1) but legacy proccesses require us to keep the publishing-info-* artifacts.

For the purpose of this project, the pipeline will use the vhd-publishing-info.json from the sku-name path (ex azurelinuxv2-gen1). (subject ot change if for readability it makes more sense to use the publishing-info-* path)

After the build step is complete, all of the artifacts should be in the pipeline directory `$(Build.ArtifactStagingDirectory)`. Using some bash, we can create a directory of just vhd-publishing-info.json files and pass it into this project in order to create the vulnerability-reporting-vms

## Testing

Please refrence the config/config.go file for all modifiable properies such as-

1. resource group
2. subscription
3. location
4. timeout

The production vulnerability-reporting-vms will be running in AME, so if you try testing without modifying the resource group and subscription, you will fail. All azure resources are created as needed, on runtime, so there is no risk running in your own resource group. Just make sure to clean up your resources when you're done!

## Deleting VMs

### TODO

We don't want to keep these vulnerability VMs running forever, therefore we only want to keep 2 releases worth of VMs running at any given time.

The VMs are tagged with their creation time. Once the new set of VMs are created we look at all VMs running in the resource group. Determine the date of the oldest set of VMs, and delete them.
2 changes: 1 addition & 1 deletion vulnerability-reporting-vms/process_json.go
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ import (

type VHD struct {
name string
ResourceID string `json:"captured_sig_resource_id"`
ResourceID string `json:"captured_sig_resource_id"` // thinking about making this a different var
ImageArch string `json:"image_architecture"`
}

Expand Down

0 comments on commit b120bd7

Please sign in to comment.