What it does here
Teleport provides privileged access. Administrators reach servers through it rather than with standing SSH credentials: access is just-in-time, protected by a mandatory second factor, and every session is recorded and replayable.
How it is deployed
Container teleport, built on Debian so recorded sessions have a real shell, running auth, proxy and node in one — the container is the managed server golonex-app-01. Behind Caddy its public address is teleport.iamlab.genbay.co; see Installation §4.6.
Settings in the web console
Your first visit is a one-time invite link, not a password — see Appendix §A.5.
First sign-in: password + second factor
The invite asks you to set a password and enrol an authenticator app. Teleport 18 will not let you turn MFA off, which is the correct posture for privileged access and worth noticing: the tool encodes the policy rather than trusting you to configure it.
Resources — what you are allowed to reach
Resources lists the servers your roles permit. You should see golonex-app-01, labelled env: production. Connect and you get a terminal in the browser as golonex-ops.
You never typed a server password, and none is stored on your machine — Teleport issued a short-lived certificate instead. That is the heart of modern PAM.
Session recordings — the accountability
Session Recordings lists every session, with a player. Open your own and watch it back keystroke by keystroke.
This is what auditors ask for and what CRD 7 means by accountability: not just who had access, but what they did with it.
Access — roles and users
Under Access (users and roles) sits the role golonex-pam-ops. It defines the whole grant in a few lines:
| Setting | Value here | Meaning |
|---|---|---|
| Logins | golonex-ops | the only OS user you may become |
| Node labels | env: production | you may reach production servers only |
| Max session TTL | 8 hours | access expires — nothing is permanent |
| Record session | on | recording is not optional |
Audit log
The audit log records logins, session starts and ends, and certificate issuance. Alongside Keycloak's events, this is the privileged half of your audit story.
Three ways to reach OPA
The same engine, three doors. Which one you use says a lot about what you are doing — demonstrating, operating, or debugging.
| Route | Who uses it | Good for |
|---|---|---|
| PDP console in the Portal | instructor, IT Ops | showing the policy and its decisions to a room |
| OPA's REST API from a container | engineers | asking the engine directly, with no app involved |
| Files and scripts on the host | whoever runs the lab | editing policy, watching decisions, running tests |
1 · From the app — the PDP console
IT Admin › Policy decision point
Sign in to the Portal as a user holding it-admins and open IT Admin › Open PDP console. Two tabs:
- Live decisions — recent authorization decisions with user, action, amount, ALLOW / DENY and the reason OPA gave. Click around the Portal in another tab, then refresh this one.
- Policy — the Rego OPA is actually running, read live from the engine rather than from disk, so the page cannot show you something that is not in force. Read-only by default.
An Edit policy button turns that tab into an editor. Saving needs the policy.edit entitlement, applies to OPA immediately, and is written to disk so it survives a restart.
It is fail-safe. OPA compiles the policy before accepting it. A Rego error is rejected with a message and the running policy is untouched — a bad edit cannot take the lab down.
Worth saying out loud to candidates: editing authorization from a web form is a teaching device, not a production pattern. Real policy lives in version control, is reviewed, tested in CI and shipped as a bundle. This console exists so you can feel a policy change take effect — which is precisely why change control matters.
2 · From a container — OPA's own API
OPA listens on opa:8181 on the internal network. It is not published to the host and not exposed through Caddy: the API has no authentication, so it must never leave the private network. Ask it from any container on ciam-net.
Ask for a decision — no app, no login, no session:
docker exec -i portal python -c "import requests;print(requests.post('http://opa:8181/v1/data/golonex/portal/decision',json={'input':{'user':'x','groups':['app-users','finance-ap-approver'],'action':'payment.approve','amount':50001}}).json())"See what policies are loaded:
docker exec portal python -c "import requests;print([p['id'] for p in requests.get('http://opa:8181/v1/policies').json()['result']])"The endpoints that matter: GET /v1/policies (what is loaded), POST /v1/data/golonex/portal/decision (ask), PUT /v1/policies/<id> (replace — this is what the console uses), and GET /health.
3 · From the host — files, scripts and logs
The policy is a plain file on the server, bind-mounted into the container at /policies:
| Path | What it is |
|---|---|
/opt/ciam-lab/opa/policies/portal.rego | the live policy |
/opt/ciam-lab/opa/policies/portal.rego.orig | pristine copy — the restore point for the live-edit demo |
/opt/ciam-lab/opa/policies/portal_test.rego | the policy's own unit tests |
/opt/ciam-lab/opa-ask.sh | ask OPA a question from the command line |
/opt/ciam-lab/opa-watch.sh | live feed of every decision — put it on a projector |
Ask a question:
/opt/ciam-lab/opa-ask.sh payment.approve app-users,finance-ap-approver 50001Watch decisions live (Ctrl-C to stop):
/opt/ciam-lab/opa-watch.shRun the policy's unit tests:
docker exec opa /opa test /policies -vRaw decision log — every decision, with full input and result:
docker logs --tail 20 opa--watch, so a change to portal.rego on disk takes effect only after
docker restart opa — about four seconds, during which the Portal fails closed and denies
everything. The PDP console sidesteps this: it pushes policy through the API, which applies instantly with no
restart.Every decision is audited
The Portal writes one JSON line per decision, and Wazuh turns the interesting ones into alerts:
| Rule | Level | Fires on |
|---|---|---|
100201 | 4 | any denied action, naming the user and the reason |
100202 | 5 | a payment approved, with the amount |
100203 | 4 | an HR record changed — workforce data feeding IGA |
100204 | 4 | an invoice created |
100205 | 10 | the authorization policy itself was changed |
100210 | 10 | a segregation-of-duties violation blocked at the PDP |
Rule 100205 is deliberately the loudest thing in the lab. Ask a candidate why that is right: changing the policy changes every future decision, so it outranks any single denied action.
Try this
- Open a session, run
whoamiandhostname, close it, then replay the recording. - Compare it with Guacamole: two different routes to a recorded privileged session, with different strengths.