15. November 2022

[dimakuv]

Agenda

(please write your proposed agenda items in comments under this discussion)

• Vijay and Dmitrii: Discuss Inter-operable RA-TLS support in Gramine.

Opens

Credits for Microsoft Azure subcription

Mona: CCC may give us money to get access to Microsoft Azure subscription (get credits).

Woju doesn't like this -- what if we use MS Azure for our CI and run out of credits in the middle of the year/month? Then the machines will be removed from the CI, suddenly we cannot test some logic in Gramine, and code will bit-rot.

Mona: The amount of credits should be per-month, such that it is always enough for CI machines to run.

Woju is afraid that while setting Jenkins for public clouds like MS Azure, we may break/misconfigure something, and we'll eat up all our credits for the month/year in one day, and we'll have to either pay for more credits or wait until they "replenish" later.

Need discussions on cloud- and HSM-specific plugins

Mona: Add to the agenda for the next meeting the topic "Plugins located in separate repos (cloud-specific, HSM-specific)". Need to discuss it, especially with @mkow (who was missing from today's meeting). This discussion is also relevant to the CI discussion.

Microsoft Azure Attestation plugin for RA-TLS urgency

Mona: there is some urgency to put MAA plugin for RA-TLS somewhere in the repos. Do we need to create an Azure-specific repo now?

General ideas on "plugins in separate repos"

Woju wants to create a new gramine-azure-integration GitHub repo, which will contain MAA + AKV (for SecretProv) + AKV (for enclave signing). Technically this repo should have an Azure-specific CI (but this will require some time to agree on and to setup).

Dmitrii: How do we integrate GSC with MS Azure?

Woju: No need to have a "GSC plugin" in gramine-azure-integration repo, but just introduce command-line args to GSC (like gsc build --with-azure). So, modify GSC in its own repo to work with these cloud-specific and HSM-specific plugins.

Dmitrii: What do we do about non-cloud-specific HSMs like OpenSSL Engine (for signing enclaves with HSM-hold keys)?

Woju: OpenSSL Engine provides the API, but end users still need to add logging, access controls, etc. So we must somehow make it explicit (in Documentation, or pop up prompts, some kind of unfinished solution). We put such things in the contrib repo.

FOSDEM 2023

There will be a FOSDEM conference again, in Brussels on February 4 & 5 2023, see https://falder.org/fosdem23-cfp . The deadline for talk submission is December 2 2022.

Dmitrii cannot attend the conference for personal reasons.

Woju may attend the conference anyway, so maybe he can also present Gramine / new features (like EDMM). @woju @mkow to discuss this internally. We'll also discuss it in the next meeting (the deadline is very soon!).

Vijay and Dmitrii: Discuss Inter-operable RA-TLS support in Gramine

Vijay: The Enclave-CC Key Broker service runs in an Occlum enclave. Apps run in a Gramine enclave. They need to attest each other, so there is a need for some interoperable RA-TLS solution. Occlum already created the Interoperable RA-TLS implementation (inclavare-containers/librats#70).

Dmitrii: started Gramine implementation of Interoperable RA-TLS in #1039. [ Dmitrii explained Interoperable RA-TLS ]. See also presentation here: https://github.com/CCC-Attestation/meetings/blob/main/materials/ShanweiCen_Interoperable_ATLS.pdf

Dmitrii needs to talk to Occlum folks and Shanwei Cen (from Intel) to choose dummy hard-coded OIDs/CBOR tags for now (before their standardization with IANA), and iron out some details (PEM vs DER, etc.).

Dmitrii: Interoperable RA-TLS will be in the core Gramine repo. Both legacy RA-TLS OID and the new standard OID will co-exist in the same self-signed X.509 certificate, at least for some transition period (it only adds ~2KB to the certificate, so not important). New apps will search for the new OID, old apps will search for the legacy OID -- both will work.

[mkow]

General ideas on "plugins in separate repos"

Woju wants to create a new gramine-azure-integration GitHub repo, which will contain MAA + AKV (for SecretProv) + AKV (for enclave signing). Technically this repo should have an Azure-specific CI (but this will require some time to agree on and to setup).

I think we've already discussed this, but I'm strongly against splitting it into multiple repositories. I'd just create a single repo named like "integrations", "plugins" or "cloud-integrations" and create a subdirectory "Azure" there. It will be much less burden to maintain for us, and just simpler in general.

[dimakuv]

Looks like we'll need to discuss it again :(

I'd be in favor of just putting everything in contrib repo, at least for now.

[monavij]

yes, maybe just use contrib for now as we figure out the repo structure.