123 lines
4.2 KiB
Org Mode
123 lines
4.2 KiB
Org Mode
#+TITLE: NIMF Milestone 2
|
||
#+SUBTITLE: Authentication and Authorization
|
||
#+AUTHOR: Adam Mohammed
|
||
|
||
* Overview
|
||
|
||
This document discusses the authentication and authorization between Metal
|
||
and Fabric focussed on the customer's experience. We want to deliver a
|
||
seamless user experience that allows users to set up connections
|
||
directly from Metal to any of the Cloud Service Providers(CSPs) they
|
||
leverage.
|
||
|
||
* Authentication
|
||
|
||
** Metal
|
||
|
||
There are a number of ways to authenticate to Metal, but ultimately it
|
||
comes down to the mode that the customer wishes to use to access their
|
||
resources. The main methods are directly as a user signed in to a web
|
||
portal and directly against the API.
|
||
|
||
Portal access is done by having the OAuth flow which lets the browser
|
||
obtain a JWT that can be used to authenticate against the Metal
|
||
APIs. It's important to understand that the Portal doesn't make calls
|
||
as itself on behalf of the user, but the user themselves are making
|
||
the calls by way of their browser.
|
||
|
||
Direct API access is done either through static API keys issued to a
|
||
user, or a project. Integrations through tooling or libraries built
|
||
for the language are also provided.
|
||
** Fabric
|
||
|
||
* Authorization
|
||
|
||
** Metal
|
||
|
||
** Fabric
|
||
|
||
|
||
|
||
Option 4 - Asynchronous Events
|
||
|
||
Highlights:
|
||
- Fabric no longer makes direct calls to Metal, it only announces that the connection is ready
|
||
- Messages are authenticated with JWT
|
||
- Metal consumes the events and modifies the state of resources as a controller
|
||
|
||
|
||
Option 5 - Callback/Webhook
|
||
|
||
|
||
|
||
Highlights
|
||
|
||
Similar to Option 4, though the infrastructure is provided by Metal
|
||
|
||
Fabric instead emits a similarly shaped event that says connections state have changed
|
||
|
||
It’s Metal’s responsibiity to consume that and respond accordingly
|
||
|
||
Changes Required
|
||
|
||
Fabric sends updates to this webhook URL
|
||
|
||
Metal consumes messages on that URL and handles them accordingly
|
||
|
||
Metal provides way to see current and desired state
|
||
|
||
Advantages
|
||
|
||
Disadvantages
|
||
|
||
* Documents
|
||
|
||
** Equinix Interconnections
|
||
|
||
Metal provided interconnections early on to give customers access to the
|
||
network capabilities provided by Fabric and Network Edge.
|
||
|
||
There currently two basic types of interconnections, a dedicated
|
||
interconnection and a shared one. The dedicated version as it sounds
|
||
uses dedicated port infrastructure that the customer owns. This is
|
||
often cost prohibitive so interconnections over Equinix owned shared
|
||
infrastructure fills that space.
|
||
|
||
The dedicated interconnection types have relatively simple logic in
|
||
the API relative to shared interconnections. A dedicated
|
||
interconnection gives you a layer 2 connection and that's all, the
|
||
rest is on the customer to manage.
|
||
|
||
Shared connections connect metal to other networks either through
|
||
layer 2 or layer 3.
|
||
|
||
Layer 2 interconnections are created using either the
|
||
=VlanFabricVCCreateInput= or the =SharedPortVCVlanCreateInput=. The
|
||
former provides the interconnection using service tokens, used by
|
||
Metal to poll the status of the interconnections. These allowed us to
|
||
provide customers with connectivity, but a poor experience because if
|
||
you look at the connection in Fabric, it's not clear how it relates to
|
||
Metal resources.
|
||
|
||
The =SharedPortVCVlanCreateInput= allows Fabric access to the related
|
||
network resources on the Metal side which means managing these network
|
||
resources on Fabric is a little bit easier. This type of
|
||
interconnection did some groundwork to bring our physical and logical
|
||
networks between Metal and Fabric closer together, but that's mostly
|
||
invisible to the customer, but enables us to build products on our
|
||
network infrastructure that weren't previously possible.
|
||
|
||
Currently, both methods of creating these interconnections exist,
|
||
until we can deprecate the =VlanFabricVCCreateInput=. The
|
||
=SharedPortVCVlanCreateInput= type is only capable of layer 2
|
||
interconnections to Amazon Web Services. This new input type allows
|
||
fabric to start supporting more layer 2 connectivity without requiring
|
||
any work on the Metal side. Once we reach parity with the connection
|
||
destinations of =VlanFabricVCCreateInput= we can deprecate this input
|
||
type.
|
||
|
||
Layer 3 interconnections are created by passing the
|
||
=VrfFabricVCCreateInput= to the interconnections endpoint. These
|
||
isolate customer traffic by routing table instead of through VLAN
|
||
tags.
|