weiguoqiang/cert-manager
1
0
Fork 0
Code Issues Pull Requests Actions 3 Packages Projects Releases Wiki Activity

Update docs with word changes

Browse Source 
Signed-off-by: joshvanl <vleeuwenjoshua@gmail.com>
This commit is contained in:
joshvanl 2021-03-26 11:13:30 +00:00
parent 2314c2c16a
commit 0d7fa077f8
1 changed files with 11 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
design/20190708.certificate-request-crd.md
View File

@ -203,7 +203,7 @@ CertificateRequest with a Denied condition will never be signed.
##### Behaviour
The Approved and Denied conditions are two distinct condition types on the
CertificateRequest. These conditions must always have the status of True, and
CertificateRequest. These conditions must only have the status of True, and
are mutually exclusive (i.e. a CertificateRequest cannot have an Approved and
Denied condition simultaneously). This behaviour is enforced in the cert-manager
validating admission webhook.
@ -232,8 +232,8 @@ certificates.k8s.io CertificateSigningRequest resource that utilises `approval`,
as CustomResourceDefinitions may [only define `/status` or `/scale`
sub-resources](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#subresources).
Approvers must therefore have permissions to update the status sub-resource of
CertificateSigningRequests. Approvers missing this permissions will have their
request rejected by the API server.
CertificateRequests. Approvers missing this permissions will have their request
rejected by the API server.
Setting the Approved or Denied conditions are restricted by the approver having
sufficient RBAC permissions. These permissions are based upon the request
@ -274,7 +274,7 @@ that is performed in the cert-manager Webhook component when a user attempts to
set the Approve or Denied condition. The user of the approver is tested along
with the IssuerRef of the CertificateRequest.
If the user does not have sufficient permissions defined above to set the
If the approver does not have sufficient permissions defined above to set the
Approved or Denied conditions, the request will be rejected by the cert-manager
validating admission webhook.
@ -331,9 +331,9 @@ and `bar`:
##### Webhook signer string building
The validating admission webhook is responsible for making SubjectAccessReviews
to evaluate whether the user has [sufficient permissions to add the Approved or
Denied conditions](#rbac). The webhook will attempt to first check whether the
use can approve all signers in all namespaced (wildcard), and if this fails,
to evaluate whether the approver has [sufficient permissions to add the Approved
or Denied conditions](#rbac). The webhook will attempt to first check whether
the use can approve all signers in all namespaced (wildcard), and if this fails,
whether it can approve for the exact signer (`.<signer-name>` or
`<signer-namespace>.<signer-name>`).
@ -351,10 +351,10 @@ The cert-manager controller is deployed with an internal approver controller.
This controller will attempt to Approve *all* CertificateRequests that are
created, regardless of its contents or IssuerRef.
By default, this approver is given the permission to sign all internal signers,
that is `Issuer` and `ClusterIssuer` `cert-manager.io` signers. This means its
ClusterRole is given the `resourceNames`: `issuers.cert-manager.io/*` and
`clusterissuers.cert-manager.io/*`
By default, this approver is given the permission to approve all internal
signers, that is `Issuer` and `ClusterIssuer` `cert-manager.io` signers. This
means its ClusterRole is given the `resourceNames`: `issuers.cert-manager.io/*`
and `clusterissuers.cert-manager.io/*`
External issuers may consider whether they wish to install further RBAC that
would allow the cert-manager approver controller to also approve