home/cert-manager
2
0
Fork 0
mirror of https://github.com/wahyd4/cert-manager.git synced 2026-08-09 05:06:38 +10:00
Code Issues Packages Projects Releases Wiki Activity

Adds some minor spelling and grammar

Browse Source 
Signed-off-by: joshvanl <vleeuwenjoshua@gmail.com>
This commit is contained in:
joshvanl
2021-07-26 13:29:50 +01:00
parent 52a2ae599d
commit eeef422165
1 changed files with 10 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
design/20210209.certificates.k8s.io-adoption.md
+10 -10
View File
@@ -54,7 +54,7 @@ the core Kubernetes resource type. This gives cert-manager the ability to
integrate with components that it otherwise wouldn't have, without changes to the
third-party project.
Having the "request" resource managed inside the API server has better a
Having the "request" resource managed inside the API server has a better
security profile (i.e. `UserInfo` fields are managed by the API server rather
than a configurable webhook,
[see](https://github.com/jetstack/cert-manager/pull/3630)).
@@ -66,8 +66,8 @@ to be installed and the webhook ready for consumers/clients of this API to make
requests.
Support for the `CertificateSigningRequest` resource in cert-manager is a
stepping stone to migrating to this resource in favour of the
`CertificateRequest` resource, if the project does indeed want to migrate.
stepping stone to migrating to this resource instead of the `CertificateRequest`
resource, if the project does indeed want to migrate.
### Goals
@@ -88,13 +88,13 @@ Bellow are a summary of properties of the `CertificateSigningRequest` which
cause issues or caveats which need to be addressed when adding support for the
resource.
### Read all access to `CertificateSigningRequests`
### Read all access to CertificateSigningRequests
`CertificateSigningRequests` are cluster scoped resources, whereas
`CertificateRequests` are not. This means that in order for users to have the
same debugging and usage capabilities of the `CertificateRequest`, users will
have the ability to list all requests in the cluster, rather than being scoped to
specific namespaces.
specific namespaces. This is a regression in security.
A solution to this problem could be given to users by providing examples or
guides to external tooling (e.g. [Open Policy Agent
@@ -103,19 +103,19 @@ can limit users access to certain `CertificateSigningRequests` based on label
selectors.
### Namespaced issuers referenced by `CertificateSigningRequest`
### Namespaced issuers referenced by CertificateSigningRequest
`CertificateSigningRequests` are cluster scoped resources, whereas
`CertificateRequests` are not. cert-manager has the concept of of namespaced
issuers that may only be referenced by `CertificateRequests` that reside in
the same namespace. Since `CertificateSigningRequests` can reference any
namespaced `Issuer`, there must be some mechanism to prevent privilege
escalation.
escalation (Alice references an issuer in Bob's namespace).
cert-manager will enforce an
[RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) noun and
verb whereby the requester must have this role bound to them, in order for the
`CertificateSigningRequest` referencing a namespaced `Issuer`, be approved by the
`CertificateSigningRequest` referencing a namespaced `Issuer` be approved by the
cert-manager controller. See [here](#conditions).
This will be done via a
@@ -160,8 +160,8 @@ signers if and when the migration to `CertificateSigningRequests` occurs.
## Proposal
cert-manager will support both `CertificateRequest` and
`CertificateSigningRequest` types until and if the project completely migrates to
the `CertificateSigningRequest` resource. The `Certificates` controller will
`CertificateSigningRequest` types until, and if, the project completely migrates
to the `CertificateSigningRequest` resource. The `Certificates` controller will
continue to create `CertificateRequest` resources, unless a flag is changed on
the cert-manager controller. This default can be switched in future.