From 7450fb6c8e9937e43fd5f0f95f2caa674413e3eb Mon Sep 17 00:00:00 2001 From: Ryan Richard Date: Fri, 22 Jul 2022 09:26:24 -0700 Subject: [PATCH] A few more small changes to the dynamic clients proposal --- .../1125_dynamic-supervisor-oidc-clients/README.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/proposals/1125_dynamic-supervisor-oidc-clients/README.md b/proposals/1125_dynamic-supervisor-oidc-clients/README.md index d44546cb..0862c70a 100644 --- a/proposals/1125_dynamic-supervisor-oidc-clients/README.md +++ b/proposals/1125_dynamic-supervisor-oidc-clients/README.md @@ -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`). - `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 - 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 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-` 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 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 @@ -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 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 -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). 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. 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 -such as `pinniped-cli`, it will not be valid and will not be usable. For the time being, the hardcoded `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 -will be confidential clients). +that starts with `client.oauth.pinniped.dev-`. Users will be prevented from creating CRs without this prefix, thus +it will not be possible to create a dynamic client CR with a name such as `pinniped-cli`. +For the time being, the hardcoded `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 will be confidential clients). 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`