OBJECT
KubernetesKindServiceAccount
ServiceAccount binds together: a name, understood by users, and perhaps by peripheral systems, for an identity a principal that can be authenticated and authorized * a set of secrets
link GraphQL Schema definition
- type KubernetesKindServiceAccount implements KubernetesResourceInterface, Node {
- # Kubernetes resource API version
- : String!
- # AutomountServiceAccountToken indicates whether pods running as this service
- # account should have an API token automatically mounted. Can be overridden at the
- # pod level.
- : Boolean
- # Resource context
- : KubernetesResourceContext!
- # Node-compatible globally unique opaque ID field
- : ID!
- # LocalObjectReference contains enough information to let you locate the
- # referenced object inside the same namespace.
- : [KubernetesKindServiceAccountImagePullSecrets]
- # Raw JSON response as produced by KRM API
- : JSON!
- # Kubernetes resource kind coming from resourceKind.kind
- : String!
- # Standard object's metadata. More info:
- # https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
- : KubernetesResourceMetadata!
- # name field, taken from metadata.name
- : String!
- # Relationships to other nodes
- : KubernetesKindServiceAccountRelationships!
- # Kubernetes resource kind metadata
- : KubernetesResourceKind!
- # 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 many
- # fields which are not generally honored. For instance, 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 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
- # .
- : [KubernetesKindServiceAccountSecrets]
- # Raw YAML response as produced by KRM API
- : String!
- }