djpbessems/ContainerImage.Pinniped
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

A few more small changes to the dynamic clients proposal

Browse Source
This commit is contained in:
Ryan Richard 2022-07-22 09:26:24 -07:00
parent b507604b90
commit 7450fb6c8e
1 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
proposals/1125_dynamic-supervisor-oidc-clients/README.md
View File

@ -174,7 +174,7 @@ A brief description of each field:
- `phase`: This enum (`Pending`,`Ready`,`Error`) summarizes the overall status of the client (defaults to `Pending`). - `phase`: This enum (`Pending`,`Ready`,`Error`) summarizes the overall status of the client (defaults to `Pending`).
- `totalClientSecrets`: The number of client secrets that are currently associated with this client. - `totalClientSecrets`: The number of client secrets that are currently associated with this client.
- `conditions`: The result of validations performed by a controller on these CRs will be written by the controller on - `conditions`: The result of validations performed by a controller on these CRs will be written by the controller on
the status. And example condition is showed above, and other conditions will also be added by the controller. the status. An example condition is shown above, and other conditions will also be added by the controller.
All `.spec` list fields (i.e. all of them) will be validated to confirm that they do not contain any duplicates and are All `.spec` list fields (i.e. all of them) will be validated to confirm that they do not contain any duplicates and are
non-empty. non-empty.
@ -319,7 +319,7 @@ pinniped-supervisor client.oauth.pinniped.dev-j77kz 12..xz 2
``` ```
All client secret hashes for an OAuth client will be stored in `pinniped-storage-oidc-client-secret-<metadata.uid>` where All client secret hashes for an OAuth client will be stored in `pinniped-storage-oidc-client-secret-<metadata.uid>` where
`metadata.uid` is a hashed version of the UID generated by the Kuberentes API server for the `OIDCClient` custom resource instance that `metadata.uid` is a base32 encoded version of the UID generated by the Kuberentes API server for the `OIDCClient` custom resource instance that
represents the given OAuth client. This secret will have an owner reference back to the `OIDCClient` to guarantee that represents the given OAuth client. This secret will have an owner reference back to the `OIDCClient` to guarantee that
it is automatically garbage collected if the `OIDCClient` is deleted. As the client secret lookup is UID based, it is it is automatically garbage collected if the `OIDCClient` is deleted. As the client secret lookup is UID based, it is
resilient against any vulnerabilities that arise from the client ID being re-used over time. Using the UID also resilient against any vulnerabilities that arise from the client ID being re-used over time. Using the UID also
@ -327,7 +327,7 @@ prevents any issues that could arise from giving the user control over the secre
issues, validation issues, etc). Each client will have a 1:1 mapping with a Kubernetes secret - there would always be issues, validation issues, etc). Each client will have a 1:1 mapping with a Kubernetes secret - there would always be
at most one Kubernetes secret per client. Since the secret name is deterministic based on the client UID, no reference at most one Kubernetes secret per client. Since the secret name is deterministic based on the client UID, no reference
field is required on the client. Kubernetes secrets have a size limit of ~1 MB which is enough to hold many thousands field is required on the client. Kubernetes secrets have a size limit of ~1 MB which is enough to hold many thousands
of hashes. This API will enforce a hard limit of 100 secrets per client (having this many client secrets is likely a of hashes. This API will enforce a hard limit of 5 secrets per client (having this many client secrets is likely a
configuration mistake). configuration mistake).
The bulk of the aggregated API server implementation would involve copy-pasting the concierge aggregated API server The bulk of the aggregated API server implementation would involve copy-pasting the concierge aggregated API server
@ -399,10 +399,10 @@ To address all of these issues we will:
- Implicit behavioral changes to APIs are avoided as they can be difficult to understand and reason about. - Implicit behavioral changes to APIs are avoided as they can be difficult to understand and reason about.
The validation associated with dynamic clients will be used to enforce that clients have `metadata.name` set to a value The validation associated with dynamic clients will be used to enforce that clients have `metadata.name` set to a value
that starts with `client.oauth.pinniped.dev-`. Thus while it will be possible to create a dynamic client CR with a name that starts with `client.oauth.pinniped.dev-`. Users will be prevented from creating CRs without this prefix, thus
such as `pinniped-cli`, it will not be valid and will not be usable. For the time being, the hardcoded `pinniped-cli` it will not be possible to create a dynamic client CR with a name such as `pinniped-cli`.
client will not be represented in the CRD API (for a few reasons, i.e. it is a public client while all dynamic clients For the time being, the hardcoded `pinniped-cli` client will not be represented in the CRD API (for a few reasons, i.e.
will be confidential clients). it is a public client while all dynamic clients will be confidential clients).
This design subdivides all possible token exchange requested audience strings into several categories. A requested This design subdivides all possible token exchange requested audience strings into several categories. A requested
audience string may be either the word `pinniped-cli` (rejected), may contain the substring `.oauth.pinniped.dev` audience string may be either the word `pinniped-cli` (rejected), may contain the substring `.oauth.pinniped.dev`