commit	32d73486f4ea778cd3ea58e2d579e862cf67fb9c	[log] [tgz]
author	Serge Bazanski <serge@nexantic.com>	Mon Feb 01 23:49:17 2021 +0100
committer	Serge Bazanski <serge@nexantic.com>	Mon Feb 01 23:49:17 2021 +0100
tree	78e3444e0b55df55f512415dbfd34977cdca2350
parent	6c4199afe4dc4d446679b862f528e840e60925df [diff]

metropolis: introduce AAA.Escrow RPC

This is a combined proto change and design document RFC.

This implements a generic 'Escrow' methid, used to allow external
entities to log into a Metropolis cluster. This flow's subject vaguely
corresponds to 'Entity' objects from the Lifecycle DD, but this will be
more precisely defined in a subsequent change which introduces the
actual entities objects, the way they're identified, and the way they're
stored in the cluster.

In addition, this formalizes the part of the LDD in which entities are
able to perform hardware attestation on nodes. The hardware attestation
part is not fully implemented, but is placed within the bounds of the
Escrow streaming RPC. Entities might also be able to performs this
hardware attestation in a separate RPC call (having already requested a
short-lived certificate permitting access to RPC), but this is not yet
sure.

This design, is in a way, a modernized version of GSSAPI. It assumes it
runs over a confidential channel (TLS), and that it only ever returns
x509 certificates emitted for the requesting client. It is also designed
to handle flows that we expect to use within Metropolis.

This design has some known limitations:

1) Limited decisionmaking abitility by the server to decide which proofs
   are needed - ie., the server cannot change its mind what other proofs
   are needed as the client presents some. Currently the server can
   decide the proofs only based on the parameters given by the client,
   and the initial context of the connection, ie. its originating
   address and the presented TLS certificate.
2) Limited expressibility of required proofs to the client, currently
   all listed must be fulfilled.

This, however, can be extended as the protocol evolves, and can continue
to support simple clients that handle only this protocol. Especially 2)
might be limiting us from preventing things like accepting emergency
certificates without necessarily needing an OIDC login, even though OIDC
logins are required for other kinds of certificates. We are explicitly
trying to keep things simple for now, and just not write ourselves into
a corner here.

Finally, this API should cover all scenarios expressed within T865 -
minus the entity storage part within the cluster.

Test Plan: Proto change and review process.

X-Origin-Diff: phab/D698
GitOrigin-RevId: 92892b5522a4d41d572fd4c10f24d26f72919aeb

3 files changed

tree: 78e3444e0b55df55f512415dbfd34977cdca2350

README.md

Monogon Source Monorepo

This is the main repository containing Monogon's public source code, including Metropolis.

Environment

We assume a Fedora host system provisioned using rW, and IntelliJ as the IDE.

For better reproducibility, all builds are executed in containers.

Usage

Spinning up: scripts/create_container.sh

Spinning down: scripts/destroy_container.sh

Running commands: scripts/run_in_container.sh <...>

Using bazel using a wrapper script: scripts/bin/bazel <...> (add to your local $PATH for convenience)

IntelliJ

This repository is compatible with the IntelliJ Bazel plugin. All commands run inside the container, and necessary paths are mapped into the container.

The following steps are necessary:

Install Google's Bazel plugin in IntelliJ.
Add the absolute path to your ~/.cache/bazel-nxt folder to your idea64.vmoptions (Help → Edit Custom VM Options) and restart IntelliJ:
-Dbazel.bep.path=/home/leopold/.cache/bazel-nxt
Set "Bazel Binary Location" in Other Settings → Bazel Settings to the absolute path of scripts/bin/bazel. This is a wrapper that will execute Bazel inside the container.
Use File → Import Bazel project... to create a new project from .bazelproject.

After running the first sync, everything should now resolve in the IDE, including generated code.

It's strongly recommend to use our project presets for file watchers and other IDE features. Run this command and re-open the project in order to install them:

bazel run intellij/localconfig $(pwd)

Metropolis

Run a single node cluster

Launch the node:

bazel run //:launch

Run a kubectl command:

bazel run //metropolis/cli/dbg -- kubectl describe