diff options
Diffstat (limited to 'build')
| -rw-r--r-- | build/crds/policy/policy_v1alpha1_serviceaccountaccess.yaml | 46 |
1 files changed, 27 insertions, 19 deletions
diff --git a/build/crds/policy/policy_v1alpha1_serviceaccountaccess.yaml b/build/crds/policy/policy_v1alpha1_serviceaccountaccess.yaml index a6a2c27e0..d3fa5e5ef 100644 --- a/build/crds/policy/policy_v1alpha1_serviceaccountaccess.yaml +++ b/build/crds/policy/policy_v1alpha1_serviceaccountaccess.yaml @@ -409,10 +409,17 @@ spec: type: string type: object secrets: - description: 'Secrets is the list of secrets allowed to be used - by pods running using this ServiceAccount. More info: https://kubernetes.io/docs/concepts/configuration/secret' + description: 'Secrets is a list of the secrets in the same namespace + that pods running using this ServiceAccount are allowed to use. + Pods are only limited to this list if this service account has + a "kubernetes.io/enforce-mountable-secrets" annotation set to + "true". This field should not be used to find auto-generated + service account token secrets for use outside of pods. Instead, + tokens can be requested directly using the TokenRequest API, + or service account token secrets can be manually created. More + info: https://kubernetes.io/docs/concepts/configuration/secret' items: - description: 'ObjectReference contains enough information to + description: "ObjectReference contains enough information to let you inspect or modify the referred object. --- New uses of this type are discouraged because of difficulty describing its usage when embedded in APIs. 1. Ignored fields. It includes @@ -420,24 +427,25 @@ spec: ResourceVersion and FieldPath are both very rarely valid in actual usage. 2. Invalid usage help. It is impossible to add specific help for individual usage. In most embedded - usages, there are particular restrictions like, "must - refer only to types A and B" or "UID not honored" or "name - must be restricted". Those cannot be well described when + usages, there are particular restrictions like, \"must + refer only to types A and B\" or \"UID not honored\" or \"name + must be restricted\". Those cannot be well described when embedded. 3. Inconsistent validation. Because the usages are different, the validation rules are different by usage, - which makes it hard for users to predict what will happen. 4. - The fields are both imprecise and overly precise. Kind is - not a precise mapping to a URL. This can produce ambiguity during - interpretation and require a REST mapping. In most cases, - the dependency is on the group,resource tuple and the - version of the actual struct is irrelevant. 5. We cannot - easily change it. Because this type is embedded in many locations, - updates to this type will affect numerous schemas. Don''t - make new APIs embed an underspecified API type they do not - control. Instead of using this type, create a locally provided - and used type that is well-focused on your reference. For - example, ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533 - .' + which makes it hard for users to predict what will happen. + \ 4. The fields are both imprecise and overly precise. Kind + is not a precise mapping to a URL. This can produce ambiguity + \ during interpretation and require a REST mapping. In + most cases, the dependency is on the group,resource tuple + \ and the version of the actual struct is irrelevant. 5. + We cannot easily change it. Because this type is embedded + in many locations, updates to this type will affect numerous + schemas. Don't make new APIs embed an underspecified API + type they do not control. \n Instead of using this type, create + a locally provided and used type that is well-focused on your + reference. For example, ServiceReferences for admission registration: + https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533 + ." properties: apiVersion: description: API version of the referent. |