INPUT_OBJECT

KubernetesKindServiceAccountInput

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

  • input KubernetesKindServiceAccountInput {
  • # APIVersion defines the versioned schema of this representation of an object.
  • # Servers should convert recognized schemas to the latest internal value, and may
  • # reject unrecognized values. More info:
  • # https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
  • apiVersion: String
  • # AutomountServiceAccountToken indicates whether pods running as this service
  • # account should have an API token automatically mounted. Can be overridden at the
  • # pod level.
  • automountServiceAccountToken: Boolean
  • # LocalObjectReference contains enough information to let you locate the
  • # referenced object inside the same namespace.
  • imagePullSecrets: [KubernetesKindServiceAccountImagePullSecretsInput]
  • # Kind is a string value representing the REST resource this object represents.
  • # Servers may infer this from the endpoint the client submits requests to. Cannot
  • # be updated. In CamelCase. More info:
  • # https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
  • kind: String
  • # Standard object's metadata. More info:
  • # https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
  • metadata: KubernetesResourceMetadataInput
  • # 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
  • # .
  • secrets: [KubernetesKindServiceAccountSecretsInput]
  • }

link Require by