Security & Authentication Matrix

This page answers "does this combination work, and what do I need for it?" in a few tables: which ways of logging in go with which Security type, what each SASL mechanism needs, which certificate and key formats go where, what the Schema Registry, Kafka Connect and ksqlDB connections support next to the brokers, and which methods each managed service offers. It's a map, not a manual: every cell links to the page that explains the setting, mostly Security & Authentication and Provider Recipes.

In the tables, Yes means it works, a half circle means it works with a catch (read the cell), and a dash means it doesn't apply or isn't available.

Security types and authentication

The security type decides whether the connection is encrypted (TLS) and whether you log in with SASL. It has to match the broker listener behind your bootstrap port. Read down a column to see what a listener of that type lets you use:

A security type that doesn't match the listener rarely says so: it usually ends in Timed out waiting for a node assignment (see Testing and common errors). Settings in a section the type hides are kept, but not sent.

SASL mechanisms

What each SASL type needs on the Kafka Security tab, and whether its secret stays out of your clusters.json file, which KafkIO keeps in plain text (see How passwords are stored). Start from the example named in the second column; it fills in the type and the callback handler for you.

• Any other mechanism name can be typed into SASL type; left blank, Kafka's default, GSSAPI, applies. See SASL mechanisms.
• Amazon MSK's IAM library also has an OAUTHBEARER variant (login handler IAMOAuthBearerLoginCallbackHandler), with no example of its own: see IAM.
• The OAuth and cloud sign-ins fetch tokens over HTTP themselves, without KafkIO's proxy. Behind a proxy, see JDK proxy system properties.

Key and certificate formats

Where each format can be used. The same three choices appear in every Truststore type and Keystore type list; details in Supported certificate and key formats.

KafkIO reads PKCS12 and PEM directly, so there's rarely a reason to convert; when you do want a Java keystore, see Need a JKS?. A Kerberos keytab isn't any of these: its path goes in the JAAS config.

Brokers and REST services

Schema Registry, Kafka Connect and ksqlDB are HTTP services with their own security settings, on their own tabs of the Cluster Properties dialog. Nothing is shared with the brokers' settings, or between tabs: if two connections need the same truststore, choose it on both.

By provider

Which ways of logging in each service offers, and which work with KafkIO. For the settings to choose (ports, security type, truststore) see Provider Recipes' At a glance table; each cell here links to the recipe. A local broker in Docker usually has no security at all (Local Kafka in Docker).

"No" and "Not covered" mean the recipe doesn't use that method: either the service doesn't offer it to Kafka clients, or it hasn't been described for KafkIO yet. The Confluent Platform row is ordinary Apache Kafka security, so every method in the first table works if the listener has it. If a method you need isn't here, the fields on the Kafka Security tab are standard Kafka client settings: your provider's settings for Java clients go into the matching fields.

Related

• Security & Authentication
• Provider Recipes
• Schema Registry Connection
• Kafka Connect Connections
• ksqlDB Connections
• Network, Proxy & Trust
• JKS Converter