cilium/cilium · error

unknown requested auth type: %s

Error message

unknown requested auth type: %s

What it means

authenticate() looks up the handler registered for the authType stored in the auth key. If no handler is registered for that type, authentication cannot proceed and this error is returned, meaning policy requires an auth type the manager does not support.

Source

Thrown at pkg/auth/manager.go:194

	return true
}

// clearPendingAuth marks the pending authentication as finished.
func (a *AuthManager) clearPendingAuth(key authKey) {
	a.logger.Debug("Clearing pending authentication", logfields.Key, key)

	a.mutex.Lock()
	defer a.mutex.Unlock()
	delete(a.pending, key)
}

func (a *AuthManager) authenticate(key authKey) error {
	a.logger.Debug("Policy is requiring authentication", logfields.Key, key)

	// Authenticate according to the requested auth type
	h, ok := a.authHandlers[key.authType]
	if !ok {
		return fmt.Errorf("unknown requested auth type: %s", key.authType)
	}

	nodeIP := a.nodeIDHandler.GetNodeIP(key.remoteNodeID)
	if nodeIP == "" {
		return fmt.Errorf("remote node IP not available for node ID %d", key.remoteNodeID)
	}

	authReq := &authRequest{
		localIdentity:  key.localIdentity,
		remoteIdentity: key.remoteIdentity,
		remoteNodeIP:   nodeIP,
	}

	authResp, err := h.authenticate(authReq)
	if err != nil {
		return fmt.Errorf("failed to authenticate with auth type %s: %w", key.authType, err)
	}

View on GitHub (pinned to ac7b90affa)

Solutions

1. Check policy/CiliumNetworkPolicies for authentication modes requesting auth types not enabled in this cilium build; adjust policy to supported types
2. Ensure the matching auth handler (e.g. SPIRE) is enabled and registered at startup
3. After upgrades/downgrades, restart or flush stale auth map entries written with unknown auth types
4. Verify all nodes in the cluster run compatible cilium versions so keys aren't written with unsupported types
5. Add the missing authType to the manager's handler set if this is a custom build

Example fix

// before
h, ok := a.authHandlers[key.authType]
if !ok {
    return fmt.Errorf("unknown requested auth type: %s", key.authType)
}
// after
h, ok := a.authHandlers[key.authType]
if !ok {
    a.logger.Warn("dropping auth entry with unknown auth type", logfields.Key, key)
    return a.authmap.Delete(key) // clean up stale entry instead of failing repeatedly
}

// Verify policy auth modes against supported handlers before applying policy
for _, mode := range policyAuthModes {
    if !supportedAuthTypes.Contains(mode) {
        return fmt.Errorf("policy requires unsupported auth type %s", mode)
    }
}

err := authenticate(key)
if err != nil && strings.HasPrefix(err.Error(), "unknown requested auth type") {
    log.Warn("unsupported auth type requested; flush stale map entries and fix policy", "key", key)
    _ = authmap.Delete(key)
}

When it happens

Trigger: An authKey pulled from the auth map or policy computation carries an authType for which a.authHandlers has no entry — e.g. an entry written by an older/newer cilium version with an auth type not compiled into this binary, or handlers that failed to register at startup.

Common situations: Rolling upgrade/downgrade where datapath entries use auth types unknown to the new binary; custom builds lacking an auth handler (e.g. no SPIRE) while policy still requires that auth type; misconfigured CiliumNetworkPolicy authentication mode referencing an unavailable type; entries left in the eBPF map after features were disabled.

Related errors

• cannot merge conflicting authentication types (%s/%s)
• policy map max entries limit exceeded
• lockdown is no longer needed, but a full policy recomputatio
• policy computation result has stale revision
• duplicate named ports

AI-assisted analysis of cilium/cilium@ac7b90affa (2026-08-31). Data as JSON: /api/errors/87546c86afb6cf78. Report an issue: GitHub.