mimaison commented on code in PR #22398: URL: https://github.com/apache/kafka/pull/22398#discussion_r3396546188
########## docs/security/security-model-connect.md: ########## @@ -0,0 +1,93 @@ +--- +title: Kafka Connect Security Model +description: Apache Kafka Connect Security Model +weight: 9 +tags: ['kafka', 'docs', 'security'] +aliases: +keywords: +type: docs +--- + +<!-- + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You under the Apache License, Version 2.0 + (the "License"); you may not use this file except in compliance with + the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +--> + + +This page extends the [Apache Kafka security model](security-model) to Kafka Connect. A worker authenticates to the Kafka cluster over a configured `SASL_SSL`/`SSL` listener exactly like any other client, so everything the core model says about authentication, authorization, and transport encryption to the brokers applies unchanged. What follows covers only what Connect adds on top — chiefly its own control plane, the REST API, and the fact that it runs user-supplied code. + +## Things You Need To Know + +- **Connect inherits the broker's client security model.** Authentication to the brokers, broker-side authorization, and transport encryption are exactly as described in the [core security model](security-model). This page only describes what Connect layers on top. +- **The REST API is unauthenticated by default.** Out of the box, anyone who can reach the REST port can create, reconfigure, stop, or delete any connector. Because connectors and plugins run arbitrary code, unrestricted REST access is effectively unrestricted code execution on the worker. +- **Connect plugins run arbitrary code.** Connectors, converters, transformations, predicates, and REST extensions loaded from `plugin.path` execute in the worker JVM with its privileges. Install only plugins you trust. +- **The REST API is a shared control plane with no per-connector isolation.** There is no notion of connector ownership: any caller allowed onto the API can act on every connector and read its configuration. +- **A worker authenticates to Kafka as a single principal.** By default all connectors on a worker share that principal's identity and ACLs; Connect does not give each connector a distinct Kafka identity. A connector can override the internal clients' configuration — including credentials — unless `connector.client.config.override.policy` restricts it (see Authorization below). +- **In distributed mode, Connect stores its state in Kafka topics.** Connector configurations (including any inlined secrets), source offsets, and status live in the `config.storage.topic`, `offset.storage.topic`, and `status.storage.topic`; protect them with ACLs as you would any sensitive topic. In standalone mode, offsets are kept in a local file (`offset.storage.file.filename`) instead, so its protection is the host filesystem's responsibility. Review Comment: I see it's explained below ########## docs/security/security-model-connect.md: ########## @@ -0,0 +1,93 @@ +--- +title: Kafka Connect Security Model +description: Apache Kafka Connect Security Model +weight: 9 +tags: ['kafka', 'docs', 'security'] +aliases: +keywords: +type: docs +--- + +<!-- + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You under the Apache License, Version 2.0 + (the "License"); you may not use this file except in compliance with + the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +--> + + +This page extends the [Apache Kafka security model](security-model) to Kafka Connect. A worker authenticates to the Kafka cluster over a configured `SASL_SSL`/`SSL` listener exactly like any other client, so everything the core model says about authentication, authorization, and transport encryption to the brokers applies unchanged. What follows covers only what Connect adds on top — chiefly its own control plane, the REST API, and the fact that it runs user-supplied code. + +## Things You Need To Know + +- **Connect inherits the broker's client security model.** Authentication to the brokers, broker-side authorization, and transport encryption are exactly as described in the [core security model](security-model). This page only describes what Connect layers on top. +- **The REST API is unauthenticated by default.** Out of the box, anyone who can reach the REST port can create, reconfigure, stop, or delete any connector. Because connectors and plugins run arbitrary code, unrestricted REST access is effectively unrestricted code execution on the worker. Review Comment: I'm not sure it's `effectively unrestricted code execution on the worker`, as you can only use plugins installed on the worker, but it's still a lot of access ########## docs/security/security-model-connect.md: ########## @@ -0,0 +1,93 @@ +--- +title: Kafka Connect Security Model +description: Apache Kafka Connect Security Model +weight: 9 +tags: ['kafka', 'docs', 'security'] +aliases: +keywords: +type: docs +--- + +<!-- + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You under the Apache License, Version 2.0 + (the "License"); you may not use this file except in compliance with + the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +--> + + +This page extends the [Apache Kafka security model](security-model) to Kafka Connect. A worker authenticates to the Kafka cluster over a configured `SASL_SSL`/`SSL` listener exactly like any other client, so everything the core model says about authentication, authorization, and transport encryption to the brokers applies unchanged. What follows covers only what Connect adds on top — chiefly its own control plane, the REST API, and the fact that it runs user-supplied code. + +## Things You Need To Know + +- **Connect inherits the broker's client security model.** Authentication to the brokers, broker-side authorization, and transport encryption are exactly as described in the [core security model](security-model). This page only describes what Connect layers on top. +- **The REST API is unauthenticated by default.** Out of the box, anyone who can reach the REST port can create, reconfigure, stop, or delete any connector. Because connectors and plugins run arbitrary code, unrestricted REST access is effectively unrestricted code execution on the worker. +- **Connect plugins run arbitrary code.** Connectors, converters, transformations, predicates, and REST extensions loaded from `plugin.path` execute in the worker JVM with its privileges. Install only plugins you trust. +- **The REST API is a shared control plane with no per-connector isolation.** There is no notion of connector ownership: any caller allowed onto the API can act on every connector and read its configuration. +- **A worker authenticates to Kafka as a single principal.** By default all connectors on a worker share that principal's identity and ACLs; Connect does not give each connector a distinct Kafka identity. A connector can override the internal clients' configuration — including credentials — unless `connector.client.config.override.policy` restricts it (see Authorization below). +- **In distributed mode, Connect stores its state in Kafka topics.** Connector configurations (including any inlined secrets), source offsets, and status live in the `config.storage.topic`, `offset.storage.topic`, and `status.storage.topic`; protect them with ACLs as you would any sensitive topic. In standalone mode, offsets are kept in a local file (`offset.storage.file.filename`) instead, so its protection is the host filesystem's responsibility. + +## The REST API and the Network Boundary + +The REST API is configured with the `listeners` property (for example `http://host:port` or `https://host:port`); if unset it defaults to `http` on port 8083. In distributed mode the REST API is *also* the inter-worker transport — a request received by a follower is forwarded to the leader — so it is simultaneously a user-facing management interface and an internal control channel. `rest.advertised.host.name`, `rest.advertised.port`, and `rest.advertised.listener` control the URL other workers use to reach a node. + +Operators should: + +1. Never expose the REST API to untrusted networks or users; bind it to a management network or front it with a reverse proxy. +2. Use `admin.listeners` to separate the admin endpoints from the regular listeners, or set it to empty to disable them where they are not needed. +3. Prefer an `https` listener so that both user traffic and inter-worker forwarding are encrypted. + +## Authentication + +Connect enables no authentication on the REST API by default. There are two common ways to add it: + +- **Reverse proxy.** Terminate authentication (mTLS, OIDC, basic auth, etc.) in a proxy in front of the workers and allow only the proxy to reach the REST port. +- **REST extension.** Register an authentication extension via `rest.extension.classes`. The built-in `BasicAuthSecurityRestExtension` performs JAAS-based HTTP basic authentication. Its reference `PropertyFileLoginModule` stores credentials in cleartext and is **not** intended for production — back it with a real `LoginModule` (LDAP, a database, etc.) instead. Review Comment: > Its reference `PropertyFileLoginModule` stores credentials in cleartext and is **not** intended for production — back it with a real `LoginModule` (LDAP, a database, etc.) instead. That sentence seems weird. ########## docs/security/security-model-connect.md: ########## @@ -0,0 +1,93 @@ +--- +title: Kafka Connect Security Model +description: Apache Kafka Connect Security Model +weight: 9 +tags: ['kafka', 'docs', 'security'] +aliases: +keywords: +type: docs +--- + +<!-- + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You under the Apache License, Version 2.0 + (the "License"); you may not use this file except in compliance with + the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +--> + + +This page extends the [Apache Kafka security model](security-model) to Kafka Connect. A worker authenticates to the Kafka cluster over a configured `SASL_SSL`/`SSL` listener exactly like any other client, so everything the core model says about authentication, authorization, and transport encryption to the brokers applies unchanged. What follows covers only what Connect adds on top — chiefly its own control plane, the REST API, and the fact that it runs user-supplied code. + +## Things You Need To Know + +- **Connect inherits the broker's client security model.** Authentication to the brokers, broker-side authorization, and transport encryption are exactly as described in the [core security model](security-model). This page only describes what Connect layers on top. +- **The REST API is unauthenticated by default.** Out of the box, anyone who can reach the REST port can create, reconfigure, stop, or delete any connector. Because connectors and plugins run arbitrary code, unrestricted REST access is effectively unrestricted code execution on the worker. +- **Connect plugins run arbitrary code.** Connectors, converters, transformations, predicates, and REST extensions loaded from `plugin.path` execute in the worker JVM with its privileges. Install only plugins you trust. +- **The REST API is a shared control plane with no per-connector isolation.** There is no notion of connector ownership: any caller allowed onto the API can act on every connector and read its configuration. +- **A worker authenticates to Kafka as a single principal.** By default all connectors on a worker share that principal's identity and ACLs; Connect does not give each connector a distinct Kafka identity. A connector can override the internal clients' configuration — including credentials — unless `connector.client.config.override.policy` restricts it (see Authorization below). +- **In distributed mode, Connect stores its state in Kafka topics.** Connector configurations (including any inlined secrets), source offsets, and status live in the `config.storage.topic`, `offset.storage.topic`, and `status.storage.topic`; protect them with ACLs as you would any sensitive topic. In standalone mode, offsets are kept in a local file (`offset.storage.file.filename`) instead, so its protection is the host filesystem's responsibility. Review Comment: If you use configuration providers, only the template strings (`${alias:fields}`) is written to the config topic, not the resolved values. Still if you know a valid template string, it's often trivial to extract the secret if you have access to the REST API. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
