microsoft/confidential-sidecar-containers

This is a collection of sidecar containers that can be incorporated within confidential container groups on Azure Container Instances.

Confidential Sidecar Containers

This repository contains the code needed to build the sidecar containers used for confidential containers.

The code in this repository should be located at $GOPATH/src/microsoft/confidential-sidecar-containers.

Build Pipelines

These build pipelines run nightly based off of images created from the main branch of this repo. They are used to test the latest changes to the sidecar containers.

• 
• 
• 

Secure key release (SKR) sidecar

The docker/skr/build.sh script builds all necessary Go tools for secure key release as standalone binaries and creates a Docker image that contains them so that it can be used as a sidecar container. The skr sidecar container is executed by calling the script skr.sh. More information about the skr API can be found here.

The skr sidecar can be queried by application containers hosted in the same pod (or container group) for retrieving attestation reports and for releasing secrets from managed HSM key vaults.

The examples/skr shows an example of how the skr sidecar can be deployed and tested within a confidential container group on ACI.

Fetching an attestion report

tools/get-snp-report provides a tool which will return an SNP attestation report from the AMD PSP via linux IOCTLs. it can take a hex encoded report data value on the command line. The output is a hex encoded binary object. If piped through hex2report it can be read by people. There are two implementations inside the one tool to support the different IOCTLs requirements between linux 5.15 and 6.1 and later.

Third-party code

The AES unwrap key without padding method code was modified to implement the aes key unwrap with padding method.

Encrypted Filesystem sidecar

The docker/encfs/build.sh script builds all necessary Go tools (for encrypted filesystems) and creates a Docker image that contains them so that it can be used as a sidecar container. The encrypted filesystem sidecar container is executed by calling the script encfs.sh with a base64-encoded string as an environment variable or a command-line argument. The entry point to the sidecar is the remotefs tool which leverages the azmount tool.

The encrypted filesystem sidecar uses the SKR library to release key material from Azure Key Vault instances required for mounting the encrypted filesystems required by the application.

The examples/encfs shows an example of how the encrypted filesystem sidecar can be deployed within a confidential container group on ACI.

Dependencies

• Golang 1.19 or later
• Docker
• GCC 9.4.0 or later

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.

When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repositories using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

Trademarks

This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft trademarks or logos is subject to and must follow Microsoft’s Trademark & Brand Guidelines. Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship. Any use of third-party trademarks or logos are subject to those third-party’s policies.

confidential-sidecar-containers's Issues

Dependabot Updates

@dependabot check-updates

Handle VLek from THIM

In future VLek certs may be available rather than just VCek.
Some handling of the cert chain may need to change.

Add link to C-ACI-Scheme document

Currently it's in the private examples repo.
Once it becomes public, adding the link should be useful.

context: #17 (comment)

2.7 version container unilaterally steps on a port

Support for the grpc version of the interface exposes itself on port 50000 by default. Any customer upgrading from 2.* to 2.7 would not expect this behaviour and it may well break then.

Please improve encfs examples

Hi, I find that 'examples/encfs' is no easy to follow. But 'examples/skr' is good. Could you improve it? Refine the 'Step by Step Example' section to something what 'examples/skr' does. Thank you.

Various annoying things with the usage instructions

Need to be clear that the generatefs.sh needs to run in a wsl or linux
Be clear it is not a 5 minute job.
mHSM and blob storage account/container prerequisites.
List of apt installs - eg cryptsetup, cl-base64, go etc etc as per Saket's session
Be very clear about the ordering and the dependencies between the various json config files.
Fix the azcopy line to use az storage blob upload to avoid an extra install
az storage blob upload --file generatefs/encfs.img --container-name kengordo-encfs-container --name KenBlob --account-name kegordoencfs --sas-token 'My-SAS-Token-Of-The-Day-note-the-quotes-because-of-%-etc'
Generally less reliance on the links to other docs which are of course much more general.
Fix the base importkeyconfig.json and encfs-sidecar-args.json to use an OCT key (default) and clear out the key derivation stuff.
Screen shots.
Anything else...

Option to delete old keys?

When you keep importing keys with new expected policy hash we should remove stale ones, or provide an option to remove or disable them.

explain how to sync the filesystem startup order

"github.com/pkg/errors" is archived

https://github.com/pkg/errors

confidential-sidecar-containers/cmd/azmount/filemanager/azure.go

Line 73 in 3ef57bc

return errors.Wrapf(err, "can't parse URL string")

We need to consider replacing errors.Wrap() or finding a good fork.

Improve handling certs in test

Potentially our tests might fail because of hard coded certs

For Test_CertFetcher, we might want to stop using hard-coded cert for expectedContent's value instead we can somehow validate the cert instead.

For Test_MAA, we can fetch actual certs from a platform cert server to avoid cert expiration (This cert will last until 2029 though).

Error messages in http responses

When getting an MAA token fails (and probably other internal errors) the server forwards on the same error status as the container received instead of making its own.

Ex) AASP container gets a 400 Bad Request error from MAA, it should probably respond with a descriptive 500 error code since the call to AASP might be valid, it could be a configuration error.

Additionally, error messages from network calls should be forwarded onto the user in the form of a response to aid in debugging. Like here should return more information than saying the call was not a 200. As of now the way to debug is to set LOG_LEVEL in the sidecar and read the logs, this takes much more work when considering security policies that might not allow logging to stdout.

Error messages from encfs need review.

The error message from the “too old” encfs was not very helpful. The failure caused by not finding the UVM info, certs etc ought to have surfaced sooner.

Similar failures may happen in future, for example if the container starts in a regular, non confidential, ACI.