Add more things!

This commit is contained in:
2025-01-13 08:47:11 -05:00
parent b1291c3b52
commit 7af2dc7558
4 changed files with 272 additions and 0 deletions

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

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

View File

@@ -0,0 +1,52 @@
#+TITLE: Notes about Zorbik Wyrdweave
#+AUTHOR: Adam Mohammed
#+DATE: January 4, 2025
* Character
Zorbik Wyrdweave is the son of Thurgo Wyrdweave and Yari Wyrdweave.
What houses were they in?
Thurgo was in Ravenclaw
Yari was in Hufflepuff
** [0/0] Background Questions
- [ ] Who are their parents
Thurgo is Zorbik's dad, and he was in
Ravenclaw as well. He did decent in school, and after started
working at Gringots after his friend told him the real magic was
with Gold. Zorbik knows his dad is passionate about making money but
sees that it doesn't fulfil him and doesn't want to be like Thurgo.
He does admire that his dad has been into herbology and has always
had a small garden behind their home.
Yari is Zorbik's mother, she was excellent in school and was able to
travel to other schools to learn about different customs and ways of
thinking about Wizarding. She's always taught Zorbik how to be
compassionate and how to be considerate of other's views.
Zorbik is the only child, but grew up with lots of other part-goblin
kids in his hometown. Growing up with a bunch of other kids from part
goblin families, he learned to scheme and plan, mostly for mischief.
Physical Traits: 3' 10" - 115 pounds - Mainly in Chest and Biceps, never did leg day
- [ ] Do they have any siblings?
- [ ] Personality Traits
Zorbik grew up as an only-child, but in a tight-knit community of wizards that descended from Goblins. As part of living in that town he learned how to make friends quickly, as well as how to scheme and plan to get into all forms of mischief. After leaving his hometown to go to school, he's become anxious when alone since he's used to having his friends close.
Zorbik is the son of Thurgo and Yari Wyrdweave, who also met at Hogwarts.
Thurgo is a financial advisor at Gringotts, which he has been at since he graduated school. His friend convinced him it was the path to riches and he was instantly sold. Thurgo hasn't yet come into those promised riches but firmly believes they're just around the corner. He's a tired old man now, and Zorbik doesn't believe his father is going to get the riches he's been chasing for so long, and is weary about following in his footsteps. Zorbik does enjoy spending time with Thurgo in the garden, which is the one thing Thurgo does to keep himself sane while he dreams of his life after he's made it. Zorbik's been able to craft a few basic potions with ingredients sourced from that garden.
Yari is an intelligent Witch, who did so well in school that she became a student ambassador that travelled to other wizarding schools to form alliances. She's got friends across the world, and now uses her wits as a Diplomat to maintain peace in the Wizarding world and keeping things in harmony with the Muggles. Yari's spent lot of time teaching Zorbik the value of understanding your friends and enemies.
Personality Traits:
- Friendly
- Likes trouble and mischief
- Good at reading people's true intentions
- Distrusts people chasing riches
- Gets anxious when alone

34
home/lab-organization.org Normal file
View File

@@ -0,0 +1,34 @@
#+TITLE: Lab Organization
#+AUTHOR: Adam Mohammed
* Requirements
| Component | Software | # Deployed |
|-------------------+------------+------------|
| Metrics Database | Prometheus | 1 |
| Metrics Dashboard | Grafana | 1 |
| K8s Control Plane | Talos | 1 |
| K8s Worker Nodes | Talos | 1 |
| Git Repository | Forgejo | |
- Metrics Database Prometheus
- Metrics Dashboard Grafanaa
* Log
** Session 1
DEADLINE: <2025-01-11 Sat>
- Create FreeBSD VM
32 GB OS DISK
32 GB Workspace DISK
using Pkg-base instead of freebsd-update
Getting Bastille installed
*** TODO Get Traefik installed
*** TODO Get ForgeJo installed
*** TODO Get prometheus installed
*** TODO Get grafana installed
*** TODO Get node-exporter installed on crab
*** TODO I should re-assign this a static IP and then con
*** TODO Get PF installed