docs: include a separate page for OSS access requests

[zmb3]

OSS Teleport supports access requests in a very limited fashion. Make this clear by adding a separate page that covers the supported OSS features.

Also fix a number of other small requests and issues with the docs while we're here, and add screenshots for the web UI workflows.

Closes #4818
Closes #13175
Closes #14889
Closes #15979
Closes #22587

[zmb3]

Note to reviewers: I didn't cover the tsh flow for requesting access from the command line. Wasn't sure if I should duplicate a bunch of that info here or link to that page in some way, so I just briefly mentioned it here.

[alexfornuto]

If the tsh flow is what you're referencing with "the same CLI-based workflow", then we need to mention it somehow. That "the same" isn't referencing anything previously discussed.

[zmb3]

It's previously discussed in the admonition 5-10 lines above?

[nklaassen]

Hey, my bad, I was misremembering the requirements for this when we chatted earlier

It is not necessary to run tctl on the auth server necessarily, you just need update permissions for access_request resources in one of your roles. So you could have a reviewer role like this and use tctl remotely:

kind: role
version: v6
metadata:
  name: reviewer
spec:
  allow:
    rules:
      - resources:
        - access_request
        verbs:
        - update

Also, I believe tctl requests review will not work in OSS. This is because whatever user you give for the --author flag, they will not be allowed to review requests, because non of their roles can have spec.allow.review_requests in OSS.

So, only tctl request approve or tctl request deny should work in OSS.

[nklaassen]

My bad, should have actually tried that, I was missing the rules block in the yaml, I've updated the yaml in the original comment to a role I just tested

[alexfornuto]

Thanks for the update. I added the required lines to my reviewer role:

kind: role
metadata:
  id: BLAH
  name: reviewer
spec:
  allow:
    ...
    ...
    rules:
    - resources:
      - access_request
      verbs:
      - update
    ...
    ...

Then I logged out and in as a user with that role:

> Profile URL:        https://myhomelabdomain
  Logged in as:       alex
  Cluster:            myhomelabdomain
  Roles:              access, auditor, dba, editor, reviewer, sp-manager

But I still don't see requests:

❯ tctl requests ls
Token Requestor Metadata Resources Created At (UTC) Request TTL Session TTL Status Request Reason Resolve Reason 
----- --------- -------- --------- ---------------- ----------- ----------- ------ -------------- -------------- 


❯

Edit: PS I was still able to approve, but in this scenario the requester has to provide the request ID manually to the reviewer.

[nklaassen]

right, in order to view them you will need the read and list verbs, I should have included those

[zmb3]

So you could have a reviewer role like this and use tctl remotely:

I'm not sure we should even mention this. If you can't use tctl locally, then you're probably on Cloud, which means you can use tsh.

Adding these allow rules is a slippery slope because you can accidentally give yourself too many permissions and break the security of the access request system. What do you think about not mentioning it in the docs, even though it does work?

[alexfornuto]

If you can't use tctl locally, then you're probably on Cloud

Or you're a security tech with admin rights in Teleport, but not given direct access to the host running the auth service.
Or you can access it, but it's difficult enough to access a shell in that environment. In my case, the auth service is in a container on a server, so I need to SSH then docker exec a shell or tctl command. Or what about a k8s cluster?

Just my 2¢, do as you will.

[zmb3]

Okay @nklaassen @alexfornuto it seems this is our unresolved item.

I am hesitant to even mention how to configure RBAC to run tctl remotely here, as these rules allow you to modify any access request, including those of your own or of others. If this is done in an enterprise environment it could result in privilege escalation attacks.

Thoughts?

[nklaassen]

I agree that we should not recommend to include update rules for access requests, it gives too much power to the reviewer. Technically running tctl directly on Auth gives you even more power that could be abused, but I think it makes it clear that this should only be possible for cluster admins and avoids us publishing a dangerous config that people could copy and use without realizing it.

[alexfornuto]

I haven't completed this review, got as far as I could before the existing instructions failed.

[alexfornuto]

Because the ID is part of the command.

Suggested change

	--reason="approved access to db-support, dba is not necessary"
	--reason="approved access to db-support, dba is not necessary" \

[alexfornuto]

If the tsh flow is what you're referencing with "the same CLI-based workflow", then we need to mention it somehow. That "the same" isn't referencing anything previously discussed.

[public-teleport-github-review-bot]

@zmb3 See the table below for backport results.

Branch	Result
branch/v10	Failed
branch/v11	Create PR
branch/v12	Create PR