Authorization
sso groups
The highest level of users and groups are defined in Keycloak which uses a self-service user registration process available on any redirected login page whereby new users are added to a default least-privileged group and can be escalated to the more privileged tiers at the discretion of the admins.
Each tier is authorized via Oauth2-Proxy in accessing the requested ingresses and have been organized into the following three SSO groups.
groups
-
partners - Unrestricted access to any and all web ingresses.
-
operators - Access restricted to the CICD and DevSecOps tools used in developing products within the lab.
-
clients - Default group for new users with access restricted to GitLab.
design
It's worth pointing out that end-to-end SSO functionality is rarely free.
In keeping with the lab's second goal, Oauth2-Proxy provides the security component for SSO but often one which just redirects to the login page for whatever service is being protected. Refer to the web ingress model for more information.
HashiCorp Vault is the only deployed service with a complete end-to-end integration as it's the only service in lab which doesn't require a paid license for SSO or uses third-party plugins to work around licensing restrictions. It's the only service which needs to be integrated as it's also a secret store for the shared credentials needed in accessing the non-integrated services.
Besides Vault, the lab uses a combination of self-service user registration or shared user accounts which allow access to non-integrated services, wherever applicable.
See the below table for a quick view of each ingress, which SSO groups have access to it, and which user access features are available.
| ingress | partners | operators | clients | mapped groups ( complete sso ) |
user registration | shared user |
|---|---|---|---|---|---|---|
access01.pendragonlab.com |
yes | |||||
access02.pendragonlab.com |
yes | |||||
access03.pendragonlab.com |
yes | |||||
artifact.pendragonlab.com |
yes | |||||
as.pendragonlab.com |
yes | yes | yes | |||
auth.pendragonlab.com/admin/* |
yes | |||||
auth.pendragonlab.com/realms/* |
yes | yes | yes | yes | ||
cicd.pendragonlab.com |
yes | yes | yes | yes | ||
core01.pendragonlab.com |
yes | |||||
dns.pendragonlab.com |
yes | |||||
docker-hosted.pendragonlab.com |
||||||
docker-proxy.pendragonlab.com |
||||||
docs.pendragonlab.com/inventory.html |
yes | yes | ||||
docs.pendragonlab.com/raidvol.html |
yes | |||||
eyes.pendragonlab.com |
yes | |||||
file.pendragonlab.com |
yes | |||||
gateway-lab.pendragonlab.com |
yes | |||||
gateway-lan.pendragonlab.com |
yes | |||||
info-db.pendragonlab.com |
yes | |||||
info-view.pendragonlab.com |
yes | yes | yes | |||
kv.pendragonlab.com |
yes | yes | yes | |||
oauth.pendragonlab.com |
||||||
ping.pendragonlab.com |
||||||
resume.pendragonlab.com |
||||||
storage.pendragonlab.com |
yes |
unix system
The lab's hosts are provisioned with a series of UNIX user accounts and groups, configured in a least-privilege model. Limited escalation powers are defined in the lab_sudoers file for each account. For security purposes, all names referenced here are canonical, not the literal names which have been redacted.
These accounts are used by various automation and human entities and are distributed across the lab. All have SSH access with the exception of the superuser or root account.
NOTE : Not every user is present on every host. Though the name for each user account is consistent across all hosts, each user instance is configured with a unique, highly-complex password stored in the lab's Secrets Vault so that compromise of a single credential does not mean compromise for all instances of the user.
users
-
super- The built-in superuser account, also calledroot. -
admin- Fully-privileged administrator. -
iac- Necessarily-privileged automation account, used byhost-mgmtandcloud-mgmt. -
engineer- Designed with limited Docker capability, meant for troubleshooting and visibility. -
associate- Created for least-privilege systemd services, nosudocapabilities.
groups
-
devops- File and folder group for sharing lab resources. -
tenants- Used by containers for access to RAID Volume Samba mounts on the Docker hosts.
raid access
Separate from the UNIX system users, the RAID Volume users are only configured on the nas host and are solely used in ACL's for various RAID Volume shares. They can't shell, have no privileges and they don't have home directories. Entities authenticate against the nas Samba service using these accounts to gain access to various least-privileged shares of the RAID Volume.
NOTE - The raid group is deployed on the
naswhich is different from the tenants group deployed on the Docker hosts. Both deal with access to RAID Volume assets.
users
-
root_rw- Enables rw access to the root folder on the RAID Volume share. -
red_rw- Enables rw access to the red folder on the RAID Volume share. -
red_ro- Enables ro access to the red folder on the RAID Volume share. -
blue_rw- Enables rw access to the blue folder on the RAID Volume share. -
blue_ro- Enables ro access to the blue folder on the RAID Volume share. -
green_rw- Enables rw access to the green folder on the RAID Volume share. -
black_rw- Enables rw access to the black folder on the RAID Volume share.
groups
raid- Members have access to authorized Samba shares on the RAID Volume.
docker runtime
Every Docker image is different.
There are infinite ways that a container might need permissions. Each container in the lab is provisioned with its own reserved UID but that UID is not always enough if like some containers, there are escalated tasks being run which need higher-privileged users or applications which have their own default UIDs configured from the vendor.
Nonetheless, in developing each container, the best effort should be applied in using the provided UID to isolate the container processes on the running host.
Refer to assignments.yml for a mapping of these allocated UIDs to their deployed containers.
In addition, the UNIX group ID for the tenants group must be configured as a container's GID in order to use RAID Volume assets mounted on the Docker host.
unix assignments
For all the identities described above, refer to the following table for lab host and ID assignments.
| name | id ( if present ) | type | host | group membership |
|---|---|---|---|---|
docker00 |
||||
docker01 |
||||
docker02 |
||||
| raid | 32600 | group | nas |
|
portal |
||||
| root_rw | 32601 | user | nas |
raid |
| red_rw | 32602 | user | nas |
raid |
| red_ro | 32603 | user | nas |
raid |
| blue_rw | 32604 | user | nas |
raid |
| blue_ro | 32605 | user | nas |
raid |
| green_rw | 32606 | user | nas |
raid |
| black_rw | 32607 | user | nas |
raid |
nas |
||||
nas |
||||
| devops | 32610 | group | docker00 |
|
| devops | 32610 | group | docker01 |
|
| devops | 32610 | group | docker02 |
|
nas |
||||
portal |
||||
| tenants | 32611 | group | docker00 |
|
| tenants | 32611 | group | docker01 |
|
| tenants | 32611 | group | docker02 |
|
nas |
||||
portal |
||||
| associate | 32612 | user | docker00 |
devops |
| associate | 32613 | user | docker01 |
devops |
| associate | 32614 | user | docker02 |
devops |
| associate | 32615 | user | nas |
|
| associate | 32616 | user | portal |
|
| engineer | 32617 | user | docker00 |
devops |
| engineer | 32618 | user | docker01 |
devops |
| engineer | 32619 | user | docker02 |
devops |
nas |
||||
| engineer | 32620 | user | portal |
|
| iac | 32621 | user | docker00 |
devops |
| iac | 32622 | user | docker01 |
devops |
| iac | 32623 | user | docker02 |
devops |
| iac | 32624 | user | nas |
|
| iac | 32625 | user | portal |
|
| admin | 32626 | user | docker00 |
iac, engineer, devops |
| admin | 32627 | user | docker01 |
iac, engineer, devops |
| admin | 32628 | user | docker02 |
iac, engineer, devops |
| admin | 32629 | user | nas |
raid |
| admin | 32630 | user | portal |
iac, engineer |