kubernetes/kops · error

writing keyset: %v

Error message

writing keyset: %v

What it means

This error wraps a failure from keyStore.StoreKeyset when promoteKeypair tries to persist the keyset after updating its Primary field. After selecting the new primary kOps must write the modified keyset back to the backing store (e.g. S3, GCS, file, or the key store backend); if that write fails (permissions, connectivity, locking, serialization) the promote is aborted with this wrapped message. The cluster's keyset is left unchanged, since the write is atomic from the caller's perspective.

Source

Thrown at cmd/kops/promote_keypair.go:197

		}
	} else if item := keyset.Items[keypairID]; item != nil {
		if item.DistrustTimestamp != nil {
			return fmt.Errorf("keypair is distrusted")
		}
		if item.PrivateKey == nil {
			return fmt.Errorf("keypair has no private key")
		}
		if item.Certificate == nil {
			return fmt.Errorf("keypair has no certificate")
		}
	} else {
		return fmt.Errorf("keypair not found")
	}

	keyset.Primary = keyset.Items[keypairID]
	err = keyStore.StoreKeyset(ctx, name, keyset)
	if err != nil {
		return fmt.Errorf("writing keyset: %v", err)
	}

	fmt.Fprintf(out, "Promoted %s %s\n", name, keypairID)
	return nil
}

func completePromoteKeyset(ctx context.Context, f commandutils.Factory, options *PromoteKeypairOptions, args []string, toComplete string) ([]string, cobra.ShellCompDirective) {
	commandutils.ConfigureKlogForCompletion()

	cluster, clientSet, completions, directive := GetClusterForCompletion(ctx, f, nil)
	if cluster == nil {
		return completions, directive
	}

	keyset, _, completions, directive := completeKeyset(ctx, cluster, clientSet, args, rotatableKeysetFilter)
	if keyset == nil {
		return completions, directive
	}

View on GitHub (pinned to 4c8573c808)

Solutions

  1. Read the wrapped %v detail to identify the backend failure, then fix it — most commonly IAM permissions on the state store bucket (e.g. s3:PutObject) or restoring network access to it.
  2. Verify the --state store location is correct and writable; retry `kops promote keypair` after the backend is available.
  3. Check for versioning/object-lock or KMS key issues on the bucket that could reject the PUT, and adjust the policy or credentials.
  4. If using kops-controller-based key stores or etcd-backed stores, verify that backend's connectivity and credentials; then re-run the promote (the operation is safe to retry since nothing was written).

Example fix

// before: promote fails on write
// kops promote keypair ca 3
// -> writing keyset: error storing keyset "ca": AccessDenied ...
// after: grant write access to the state store, then retry
// aws s3api put-bucket-policy ... (allow s3:PutObject for the kops user)
// kops promote keypair ca 3
// -> Promoted ca 3
Defensive patterns

Strategy: retry

Validate before calling

// Check state store writability first, e.g. for S3:
// aws s3 cp /dev/stdin s3://<state-bucket>/test-write --content-type text/plain && aws s3 rm s3://<state-bucket>/test-write

Try / catch

err := keyStore.StoreKeyset(ctx, name, keyset)
if err != nil {
    var retryable bool
    // inspect wrapped backend error (network/timeout/throttle => retry; AccessDenied => fix IAM)
    if isNetworkOrThrottleError(err) {
        retryable = true
    }
    return fmt.Errorf("writing keyset: %v (retryable=%v)", err, retryable)
}

Prevention

When it happens

Trigger: `kops promote keypair` reaching the StoreKeyset call — i.e. the keypair was valid and selected — but the underlying write fails: no write permission on the state store bucket/prefix, network failure to the cloud object store, state store read-only or versioned/locked, or backend serialization error.

Common situations: AWS credentials lacking s3:PutObject on the state bucket; S3 bucket with Object Lock / deny policy or KMS key unavailable; offline or firewalled CI runner; state store migration (path changed, wrong --state flag pointing to a read-only replica); concurrent kOps runs conflicting on the same keyset.

Related errors


AI-assisted analysis of kubernetes/kops@4c8573c808 (2026-09-05). Data as JSON: /api/errors/0ada3287e4dae46c. Report an issue: GitHub.