adam/org-notes
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Add more things!

Browse Source
This commit is contained in:
Adam Mohammed
2025-01-13 08:47:11 -05:00
parent b1291c3b52
commit 7af2dc7558
4 changed files with 272 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

105
equinix/test-plan-staff.md Normal file
View File

@@ -0,0 +1,105 @@
# Table of Contents
1. [Staff operator portal](#org992e17b)
1. [Primary problem](#org538f8d6)
2. [Auxilliary problems](#org4412c9f)
3. [Analysis](#org9b704f7)
4. [Work to be done](#orgcad9c50)
<a id="org992e17b"></a>
# Staff operator portal
<a id="org538f8d6"></a>
## Primary problem
We don't have granular control over roles granted to "staff" users.
<a id="org4412c9f"></a>
## Auxilliary problems
- We don't support SSO / separate login path
- We don't automatically offboard staff
- Acting as a Staff requires an additional credential
<a id="org9b704f7"></a>
## Analysis
We've already implemented authorization checks using the IAM runtime,
and can extend that for staff portal usage. The Metal API doens't have
a clean separation between APIs for staff users and APIs for
customers. In some cases, depending on how you auth an endpoint can
respond differently.
The way you auth today with an Auth0 JWT or API key identifies you as
the user that we have represented in the Metal DB. Additionally, you
can supply a consumer token, and an additional header \`x-packet-staff\`
to enable access to staff features and endpoints.
In the next iteration of the staff operator portal, we would like to
be able to give staff users more fine-grained permissions, so they
only have access to the resources and actions they need to carry out
their jobs.
Miles and team have gone through and identified use cases and
potential roles that we want users to be able to have.
The identity team's role in this is determining how best to structure
the policy so that we can support the roles as well as changes to the
roles with little intervention.
With EIS services, such as token exchange and permissions api, we have
a much more dynamic system for dynamically creating and applying
permissions.
By default authenticating to the Metal API should treat you as any
other customer. If you want to perform the request as if you were a
staff user, additional context would be necessary. Right now that
additional context is the consumer token and packet staff header. With
permissions API, we would no longer need the consumer token, and we
could get by with just the packet staff header. The staff header
purpose would just be to indicate to the backend that the user wants
to act in the staff context.
SpiceDB supports passing additional context within access checks to
perform a limited form of attribute-based access control. In our case,
a sample schema may look like this: <https://play.authzed.com/s/kAikrVuvYYJ7/schema>
In this example we have a resource \`metlins-foo\` owned by a tenant
\`child0\`, which is owned by the \`root\` tenant. There are two users
\`adammo\` and \`mason\`. The user \`adammo\` is a member of the tenant that
owns the instance resource, and as a result can view details of the
instance without any additional context.
The user \`mason\` is a member of the root tenant, and if that user
tries to view details they get a response back from spicedb indicating
that the check is caveated. If the correct context is sent with the
check, viewing details is allowed, otherwise it's denied.
This setup allows us to act as both customer and staff users without
needing to change relationships on the fly.
<a id="orgcad9c50"></a>
## Work to be done
In order to implement this for the staff portal, some additional work
is necessary:
- Permissions API needs to add support for allowing caveated access
checks
- The IAM Runtime spec needs support for that API
- Permissions API policy needs to be updated with caveated policy
- Relationships need to be published with required caveats
- Metal API needs to support passing additional context to the IAM
runtime for the caveat checks

81
equinix/test-plan-staff.org Normal file
View File

@@ -0,0 +1,81 @@
* Staff operator portal
** Primary problem
We don't have granular control over roles granted to "staff" users.
** Auxilliary problems
- We don't support SSO / separate login path
- We don't automatically offboard staff
- Acting as a Staff requires an additional credential
** Analysis
We've already implemented authorization checks using the IAM runtime,
and can extend that for staff portal usage. The Metal API doens't have
a clean separation between APIs for staff users and APIs for
customers. In some cases, depending on how you auth an endpoint can
respond differently.
The way you auth today with an Auth0 JWT or API key identifies you as
the user that we have represented in the Metal DB. Additionally, you
can supply a consumer token, and an additional header `x-packet-staff`
to enable access to staff features and endpoints.
In the next iteration of the staff operator portal, we would like to
be able to give staff users more fine-grained permissions, so they
only have access to the resources and actions they need to carry out
their jobs.
Miles and team have gone through and identified use cases and
potential roles that we want users to be able to have.
The identity team's role in this is determining how best to structure
the policy so that we can support the roles as well as changes to the
roles with little intervention.
With EIS services, such as token exchange and permissions api, we have
a much more dynamic system for dynamically creating and applying
permissions.
By default authenticating to the Metal API should treat you as any
other customer. If you want to perform the request as if you were a
staff user, additional context would be necessary. Right now that
additional context is the consumer token and packet staff header. With
permissions API, we would no longer need the consumer token, and we
could get by with just the packet staff header. The staff header
purpose would just be to indicate to the backend that the user wants
to act in the staff context.
SpiceDB supports passing additional context within access checks to
perform a limited form of attribute-based access control. In our case,
a sample schema may look like this: https://play.authzed.com/s/kAikrVuvYYJ7/schema
In this example we have a resource `metlins-foo` owned by a tenant
`child0`, which is owned by the `root` tenant. There are two users
`adammo` and `mason`. The user `adammo` is a member of the tenant that
owns the instance resource, and as a result can view details of the
instance without any additional context.
The user `mason` is a member of the root tenant, and if that user
tries to view details they get a response back from spicedb indicating
that the check is caveated. If the correct context is sent with the
check, viewing details is allowed, otherwise it's denied.
This setup allows us to act as both customer and staff users without
needing to change relationships on the fly.
** Work to be done
In order to implement this for the staff portal, some additional work
is necessary:
- Permissions API needs to add support for allowing caveated access
checks
- The IAM Runtime spec needs support for that API
- Permissions API policy needs to be updated with caveated policy
- Relationships need to be published with required caveats
- Metal API needs to support passing additional context to the IAM
runtime for the caveat checks