✨ PoC: Implement user warrants

[sttts]

Summary

Needs kcp-dev/kubernetes#145.

From Slack:

🧵 long ago @sur presented a problem (if I remember right) in our current auth model of serviceaccounts only being valid locally, and with that the inability to create workspaces through an APIExport virtual workspace. The steps are these:

1. a user U creates a workspace W2 in logicalcluster L1 through an APIExport virtual workspace (that has a permission claim on Workspaces).
2. the VW forwards the requests by impersonating its system:masters user with a fake system:kcp:admin serviceaccount (S1) for L1 named system:serviceaccount:default:rest.
3. the forwarded requests hits kcp and kcp authorizes the workspace creation with that S1 serviceaccount. It uses that identity to authorize the use of workspace types. By giving use permission to everybody, this goes through.
4. workspace admission sticks S1 as owner on the workspace object, to be used by initialization later.
5. the workspace scheduler creates a logicalclusters L2 for W2 and gives S1 admin permissions through a clusterrole+binding.
6. the initializers kick in and access the initializer VW for L2 where W2 has been scheduled to. Their requests are impersonated as S1 by the VW.
7. these requests hit kcp and the authorizer denies access because S1 is a foreign service account 💥

Now assume a modified system that

• understands serviceaccounts from other workspaces, but does not give them permissions by default.
• does not use a fake serviceaccount S1 identity to pass through the APIExport VW requests, but preserves the actual controller user and only attaches a warrant that gives the requires access of the claim.

The steps from above would turn into:

1. a user U creates a workspace W2 in logicalcluster L1 through an APIExport virtual workspace (that has a permission claim on Workspaces).
2. the VW forwards the requests by impersonating its system:masters user as U with a warrant for a fake system:kcp:admin serviceaccount (S1) for L1 named system:serviceaccount:default:rest.
3. the forwarded requests hits kcp and kcp authorizes the workspace creation with that warrant S1 serviceaccount because U is not enough. It uses the U identity to authorize the use of workspace types. By giving use permission to everybody, tThis goes through.
4. workspace admission sticks U with warrant S1 as owner on the workspace object, to be used by initialization later.
5. the workspace scheduler creates a logicalclusters L2 for W2 and gives U with warrant S1 admin permissions through a clusterrole+binding.
6. the initializers kick in and access the initializer VW for L2 where W2 has been scheduled to. Their requests are impersonated as U with warrant S1 by the VW.
7. these requests hit kcp and the authorizer denies access because S1 is a foreign service account grants access because U with warrant S1 is admin in L2.

Now assume in addition that U is actually a controller serviceaccount S0 in workspace root. Step (7) would 💥 because S0 is foreign for L2. We further modify the system to authenticate serviceaccount as system:kcp:serviceaccount:<logicalcluster>:<ns>:<name> with a warrant for system:serviceaccount:<ns>:<name> restricted to their defining logicalcluster.

Now, U becomes system:kcp:serviceaccount:root:default:controller with warrant system:serviceaccount:default:controller restricted to root. With that (4) becomes

4. workspace admission sticks system:kcp:serviceaccount:root:default:controller with warrant system:serviceaccount:default:controller restricted to root with warrant S1 as owner on the workspace object, to be used by initialization later.

I.e. the user has two warrants. With that (7) becomes:

7. these requests hit kcp and the authorizer grants access because system:kcp:serviceaccount:root:default:controller with the TWO warrants including S1 is admin in L2.

Related issue(s)

Fixes #

Release Notes

Pass through original identity of controllers accessing a logical cluster through the APIExport virtual workspace. To get the required permissions, a warrant mechanism is added through user extra fields that attaches secondary user identities purely used for authorization.

[kcp-ci-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from sttts. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS
• config/crds/OWNERS
• sdk/apis/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[mjudeikis]

Should this be a scopes as it can contain multiple?

[sttts]

yes, extra is map[string][]string. But the keys are traditionally singular.

[sttts]

fixed

[mjudeikis]

authorization.kcp.io/warrants as It can the list?

[sttts]

fixed

[mjudeikis]

We talking here about local user? This is not a problem if external/oidc identity is used? What is user type here?

[sttts]

Any user. You can use scopes to scope it down to a workspace.

[kcp-ci-bot]

@sttts: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-kcp-verify	2ca96c3	link	true	/test pull-kcp-verify
pull-kcp-verify-codegen	2ca96c3	link	true	/test pull-kcp-verify-codegen
pull-kcp-test-e2e-shared	2ca96c3	link	true	/test pull-kcp-test-e2e-shared
pull-kcp-lint	2ca96c3	link	true	/test pull-kcp-lint
pull-kcp-test-e2e-sharded	2ca96c3	link	true	/test pull-kcp-test-e2e-sharded
pull-kcp-test-e2e	2ca96c3	link	true	/test pull-kcp-test-e2e
pull-kcp-test-e2e-multiple-runs	2ca96c3	link	true	/test pull-kcp-test-e2e-multiple-runs

Full PR test history

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[kcp-ci-bot]

PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.