change 'properties' identifier to 'java-properties'

Author: gomudayya

docs/security/authentication-using-sasl.md

@@ -36,7 +36,7 @@ Kafka uses the Java Authentication and Authorization Service ([JAAS](https://doc
 
 Brokers may also configure JAAS using the broker configuration property `sasl.jaas.config`. The property name must be prefixed with the listener prefix including the SASL mechanism, i.e. `listener.name.{listenerName}.{saslMechanism}.sasl.jaas.config`. Only one login module may be specified in the config value. If multiple mechanisms are configured on a listener, configs must be provided for each mechanism using the listener and mechanism prefix. For example,
 
-```properties
+```java-properties
 listener.name.sasl_ssl.scram-sha-256.sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required \
     username="admin" \
     password="admin-secret";
@@ -104,13 +104,13 @@ Kafka supports the following SASL mechanisms:
 
 1. Configure a SASL port in server.properties, by adding at least one of SASL_PLAINTEXT or SASL_SSL to the _listeners_ parameter, which contains one or more comma-separated values:
 
-   ```properties
+   ```java-properties
    listeners=SASL_PLAINTEXT://host.name:port
    ```
 
    If you are only configuring a SASL port (or if you want the Kafka brokers to authenticate each other using SASL) then make sure you set the same SASL protocol for inter-broker communication:
 
-   ```properties
+   ```java-properties
    security.inter.broker.protocol=SASL_PLAINTEXT (or SASL_SSL)
    ```
 
@@ -168,7 +168,7 @@ Note: When establishing connections to brokers via SASL, clients may perform a r
 
 4. Configure SASL port and SASL mechanisms in server.properties as described here. For example:
 
-   ```properties
+   ```java-properties
    listeners=SASL_PLAINTEXT://host.name:port
    security.inter.broker.protocol=SASL_PLAINTEXT
    sasl.mechanism.inter.broker.protocol=GSSAPI
@@ -177,7 +177,7 @@ Note: When establishing connections to brokers via SASL, clients may perform a r
 
    We must also configure the service name in server.properties, which should match the principal name of the kafka brokers. In the above example, principal is "kafka/kafka1.hostname.com@EXAMPLE.com", so:
 
-   ```properties
+   ```java-properties
    sasl.kerberos.service.name=kafka
    ```
 
@@ -186,7 +186,7 @@ Note: When establishing connections to brokers via SASL, clients may perform a r
 To configure SASL authentication on the clients: 
 1. Clients (producers, consumers, connect workers, etc) will authenticate to the cluster with their own principal (usually with the same name as the user running the client), so obtain or create these principals as needed. Then configure the JAAS configuration property for each client. Different clients within a JVM may run as different users by specifying different principals. The property `sasl.jaas.config` in producer.properties or consumer.properties describes how clients like producer and consumer can connect to the Kafka Broker. The following is an example configuration for a client using a keytab (recommended for long-running processes): 
 
-   ```properties
+   ```java-properties
    sasl.jaas.config=com.sun.security.auth.module.Krb5LoginModule required \
        useKeyTab=true \
        storeKey=true \
@@ -196,7 +196,7 @@ To configure SASL authentication on the clients:
 
    For command-line utilities like kafka-console-consumer or kafka-console-producer, kinit can be used along with "useTicketCache=true" as in: 
 
-   ```properties
+   ```java-properties
    sasl.jaas.config=com.sun.security.auth.module.Krb5LoginModule required \
        useTicketCache=true;
    ```
@@ -211,7 +211,7 @@ JAAS configuration for clients may alternatively be specified as a JVM parameter
 
 4. Configure the following properties in producer.properties or consumer.properties: 
 
-   ```properties
+   ```java-properties
    security.protocol=SASL_PLAINTEXT (or SASL_SSL)
    sasl.mechanism=GSSAPI
    sasl.kerberos.service.name=kafka
@@ -245,7 +245,7 @@ Under the default implementation of `principal.builder.class`, the username is u
 
 3. Configure SASL port and SASL mechanisms in server.properties as described here. For example: 
 
-   ```properties
+   ```java-properties
    listeners=SASL_SSL://host.name:port
    security.inter.broker.protocol=SASL_SSL
    sasl.mechanism.inter.broker.protocol=PLAIN
@@ -257,7 +257,7 @@ Under the default implementation of `principal.builder.class`, the username is u
 To configure SASL authentication on the clients: 
 1. Configure the JAAS configuration property for each client in producer.properties or consumer.properties. The login module describes how the clients like producer and consumer can connect to the Kafka Broker. The following is an example configuration for a client for the PLAIN mechanism: 
 
-   ```properties
+   ```java-properties
    sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \
        username="alice" \
        password="alice-secret";
@@ -269,7 +269,7 @@ JAAS configuration for clients may alternatively be specified as a JVM parameter
 
 2. Configure the following properties in producer.properties or consumer.properties: 
 
-   ```properties
+   ```java-properties
    security.protocol=SASL_SSL
    sasl.mechanism=PLAIN
    ```
@@ -341,7 +341,7 @@ $ bin/kafka-configs.sh --bootstrap-server localhost:9092 --alter \
 
 3. Configure SASL port and SASL mechanisms in server.properties as described here. For example: 
 
-   ```properties
+   ```java-properties
    listeners=SASL_SSL://host.name:port
    security.inter.broker.protocol=SASL_SSL
    sasl.mechanism.inter.broker.protocol=SCRAM-SHA-256 (or SCRAM-SHA-512)
@@ -353,7 +353,7 @@ $ bin/kafka-configs.sh --bootstrap-server localhost:9092 --alter \
 To configure SASL authentication on the clients: 
 1. Configure the JAAS configuration property for each client in producer.properties or consumer.properties. The login module describes how the clients like producer and consumer can connect to the Kafka Broker. The following is an example configuration for a client for the SCRAM mechanisms: 
 
-   ```properties
+   ```java-properties
    sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required \
        username="alice" \
        password="alice-secret";
@@ -365,7 +365,7 @@ JAAS configuration for clients may alternatively be specified as a JVM parameter
 
 2. Configure the following properties in producer.properties or consumer.properties: 
 
-   ```properties
+   ```java-properties
    security.protocol=SASL_SSL
    sasl.mechanism=SCRAM-SHA-256 (or SCRAM-SHA-512)
    ```
@@ -453,7 +453,7 @@ Set to a positive integer value if you wish to allow up to some number of positi
 
 3. Configure SASL port and SASL mechanisms in server.properties as described here. For example: 
 
-   ```properties
+   ```java-properties
    listeners=SASL_SSL://host.name:port (or SASL_PLAINTEXT if non-production)
    security.inter.broker.protocol=SASL_SSL (or SASL_PLAINTEXT if non-production)
    sasl.mechanism.inter.broker.protocol=OAUTHBEARER
@@ -478,7 +478,7 @@ Set to a positive integer value if you wish to allow up to some number of positi
 
 3. Configure SASL port and SASL mechanisms in server.properties as described here. For example: 
 
-   ```properties
+   ```java-properties
    listeners=SASL_SSL://host.name:port
    security.inter.broker.protocol=SASL_SSL
    sasl.mechanism.inter.broker.protocol=OAUTHBEARER
@@ -502,7 +502,7 @@ The OAUTHBEARER broker configuration includes:
 To configure SASL authentication on the clients: 
 1. Configure the JAAS configuration property for each client in producer.properties or consumer.properties. The login module describes how the clients like producer and consumer can connect to the Kafka Broker. The following is an example configuration for a client for the OAUTHBEARER mechanisms: 
 
-   ```properties
+   ```java-properties
    sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
        unsecuredLoginStringClaim_sub="alice";
    ```
@@ -589,7 +589,7 @@ JAAS configuration for clients may alternatively be specified as a JVM parameter
 
 2. Configure the following properties in producer.properties or consumer.properties: 
 
-   ```properties
+   ```java-properties
    security.protocol=SASL_SSL (or SASL_PLAINTEXT if non-production)
    sasl.mechanism=OAUTHBEARER
    ```
@@ -600,7 +600,7 @@ JAAS configuration for clients may alternatively be specified as a JVM parameter
 To configure SASL authentication on the clients: 
 1. Configure the JAAS configuration property for each client in producer.properties or consumer.properties. The login module describes how the clients like producer and consumer can connect to the Kafka Broker. The following is an example configuration for a client for the OAUTHBEARER mechanisms: 
 
-   ```properties
+   ```java-properties
    sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required ;
    ```
 
@@ -610,7 +610,7 @@ JAAS configuration for clients may alternatively be specified as a JVM parameter
 
 For example, if using the OAuth `client_credentials` grant type with a client secret to communicate with the OAuth identity provider, the configuration might look like this:
 
-   ```properties
+   ```java-properties
    security.protocol=SASL_SSL
    sasl.mechanism=OAUTHBEARER
    sasl.oauthbearer.client.credentials.client.id=jdoe
@@ -623,7 +623,7 @@ Alternatively, the `client_credentials` grant type also supports client assertio
 
 When using client assertion with dynamically-generated JWTs (recommended), the configuration might look like this:
 
-   ```properties
+   ```java-properties
    security.protocol=SASL_SSL
    sasl.mechanism=OAUTHBEARER
    sasl.oauthbearer.token.endpoint.url=https://example.com/oauth2/v1/token
@@ -639,7 +639,7 @@ When using client assertion with dynamically-generated JWTs (recommended), the c
 
 Alternatively, a pre-generated JWT assertion can be read from a file. This is useful when assertions are generated by an external process or secrets manager:
 
-   ```properties
+   ```java-properties
    security.protocol=SASL_SSL
    sasl.mechanism=OAUTHBEARER
    sasl.oauthbearer.token.endpoint.url=https://example.com/oauth2/v1/token
@@ -672,7 +672,7 @@ This selection is made at configuration time. Once a method is selected, it pers
 
 Or, if using the OAuth `urn:ietf:params:oauth:grant-type:jwt-bearer` grant type to communicate with the OAuth identity provider, the `JwtBearerJwtRetriever` must be configured explicitly since the default retriever delegates to `ClientCredentialsJwtRetriever`:
 
-   ```properties
+   ```java-properties
    security.protocol=SASL_SSL
    sasl.mechanism=OAUTHBEARER
    sasl.oauthbearer.jwt.retriever.class=org.apache.kafka.common.security.oauthbearer.JwtBearerJwtRetriever
@@ -767,13 +767,13 @@ Production use cases will also require writing an implementation of `org.apache.
 
 2. Enable the SASL mechanisms in server.properties: 
 
-   ```properties
+   ```java-properties
    sasl.enabled.mechanisms=GSSAPI,PLAIN,SCRAM-SHA-256,SCRAM-SHA-512,OAUTHBEARER
    ```
 
 3. Specify the SASL security protocol and mechanism for inter-broker communication in server.properties if required: 
 
-   ```properties
+   ```java-properties
    security.inter.broker.protocol=SASL_PLAINTEXT (or SASL_SSL)
    sasl.mechanism.inter.broker.protocol=GSSAPI (or one of the other enabled mechanisms)
    ```
@@ -857,7 +857,7 @@ Configuring Kafka Clients:
 
 1. Configure the JAAS configuration property for each client in producer.properties or consumer.properties. The login module describes how the clients like producer and consumer can connect to the Kafka Broker. The following is an example configuration for a client for the token authentication: 
 
-   ```properties
+   ```java-properties
    sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required \
        username="tokenID123" \
        password="lAYYSFmLs4bTjf+lTZ1LCHR/ZZFNA==" \

docs/security/authorization-and-acls.md

@@ -28,7 +28,7 @@ type: docs
 
 Kafka ships with a pluggable authorization framework, which is configured with the `authorizer.class.name` property in the server configuration. Configured implementations must extend `org.apache.kafka.server.authorizer.Authorizer`. Kafka provides a default implementation which store ACLs in the cluster metadata (KRaft metadata log). For KRaft clusters, use the following configuration on all nodes (brokers, controllers, or combined broker/controller nodes): 
 
-```properties
+```java-properties
 authorizer.class.name=org.apache.kafka.metadata.authorizer.StandardAuthorizer
 ```
 
@@ -42,13 +42,13 @@ If a resource (R) does not have any ACLs defined, meaning that no ACL matches th
 
 If you prefer that resources without any ACLs be accessible by all users (instead of just super users), you can change the default behavior. To do this, add the following line to your server.properties file:
 
-```properties
+```java-properties
 allow.everyone.if.no.acl.found=true
 ```
 
 With this setting enabled, if a resource does not have any ACLs defined, Kafka will allow access to everyone. If a resource has one or more ACLs defined, those ACL rules will be enforced as usual, regardless of the setting. One can also add super users in server.properties like the following (note that the delimiter is semicolon since SSL user names may contain comma). Default PrincipalType string "User" is case sensitive. 
 
-```properties
+```java-properties
 super.users=User:Bob;User:Alice
 ```
 
@@ -79,7 +79,7 @@ DEFAULT
 Above rules translate distinguished name "CN=serviceuser,OU=ServiceUsers,O=Unknown,L=Unknown,ST=Unknown,C=Unknown" to "serviceuser" and "CN=adminUser,OU=Admin,O=Unknown,L=Unknown,ST=Unknown,C=Unknown" to "adminuser@admin".   
 For advanced use cases, one can customize the name by setting a customized PrincipalBuilder in server.properties like the following. 
 
-```properties
+```java-properties
 principal.builder.class=CustomizedPrincipalBuilderClass
 ```
 
@@ -98,7 +98,7 @@ RULE:[n:string](regexp)s/pattern/replacement/g/U
 
 An example of adding a rule to properly translate user@MYDOMAIN.COM to user while also keeping the default rule in place is: 
 
-```properties
+```java-properties
 sasl.kerberos.principal.to.local.rules=RULE:[1:$1@$0](.*@MYDOMAIN.COM)s/@.*//,DEFAULT
 ```
 

docs/security/encryption-and-authentication-using-ssl.md

@@ -253,13 +253,13 @@ $ openssl x509 -in certificate.crt -text -noout
 
 If SSL is not enabled for inter-broker communication (see below for how to enable it), both PLAINTEXT and SSL ports will be necessary. 
 
-```properties
+```java-properties
 listeners=PLAINTEXT://host.name:port,SSL://host.name:port
 ```
 
 Following SSL configs are needed on the broker side:
 
-```properties
+```java-properties
 ssl.keystore.location=/var/private/ssl/server.keystore.jks
 ssl.keystore.password=test1234
 ssl.key.password=test1234
@@ -276,7 +276,7 @@ Note: ssl.truststore.password is technically optional but highly recommended. If
 6. ssl.secure.random.implementation=SHA1PRNG
 If you want to enable SSL for inter-broker communication, add the following to the server.properties file (it defaults to PLAINTEXT):
 
-```properties
+```java-properties
 security.inter.broker.protocol=SSL
 ```
 
@@ -313,15 +313,15 @@ If the certificate does not show up or if there are any other error messages the
 SSL is supported only for the new Kafka Producer and Consumer, the older API is not supported. The configs for SSL will be the same for both producer and consumer.  
 If client authentication is not required in the broker, then the following is a minimal configuration example: 
 
-```properties
+```java-properties
 security.protocol=SSL
 ssl.truststore.location=/var/private/ssl/client.truststore.jks
 ssl.truststore.password=test1234
 ```
 
 Note: ssl.truststore.password is technically optional but highly recommended. If a password is not set access to the truststore is still available, but integrity checking is disabled. If client authentication is required, then a keystore must be created like in step 1 and the following must also be configured: 
 
-```properties
+```java-properties
 ssl.keystore.location=/var/private/ssl/client.keystore.jks
 ssl.keystore.password=test1234
 ssl.key.password=test1234

docs/security/incorporating-security-features-in-a-running-cluster.md

@@ -43,56 +43,56 @@ When performing an incremental bounce stop the brokers cleanly via a SIGTERM. It
 
 As an example, say we wish to encrypt both broker-client and broker-broker communication with SSL. In the first incremental bounce, an SSL port is opened on each node: 
 
-```properties
+```java-properties
 listeners=PLAINTEXT://broker1:9091,SSL://broker1:9092
 ```
 
 We then restart the clients, changing their config to point at the newly opened, secured port: 
 
-```properties
+```java-properties
 bootstrap.servers = [broker1:9092,...]
 security.protocol = SSL
 ...etc
 ```
 
 In the second incremental server bounce we instruct Kafka to use SSL as the broker-broker protocol (which will use the same SSL port): 
 
-```properties
+```java-properties
 listeners=PLAINTEXT://broker1:9091,SSL://broker1:9092
 security.inter.broker.protocol=SSL
 ```
 
 In the final bounce we secure the cluster by closing the PLAINTEXT port: 
 
-```properties
+```java-properties
 listeners=SSL://broker1:9092
 security.inter.broker.protocol=SSL
 ```
 
 Alternatively we might choose to open multiple ports so that different protocols can be used for broker-broker and broker-client communication. Say we wished to use SSL encryption throughout (i.e. for broker-broker and broker-client communication) but we'd like to add SASL authentication to the broker-client connection also. We would achieve this by opening two additional ports during the first bounce: 
 
-```properties
+```java-properties
 listeners=PLAINTEXT://broker1:9091,SSL://broker1:9092,SASL_SSL://broker1:9093
 ```
 
 We would then restart the clients, changing their config to point at the newly opened, SASL & SSL secured port: 
 
-```properties
+```java-properties
 bootstrap.servers = [broker1:9093,...]
 security.protocol = SASL_SSL
 ...etc
 ```
 
 The second server bounce would switch the cluster to use encrypted broker-broker communication via the SSL port we previously opened on port 9092: 
 
-```properties
+```java-properties
 listeners=PLAINTEXT://broker1:9091,SSL://broker1:9092,SASL_SSL://broker1:9093
 security.inter.broker.protocol=SSL
 ```
 
 The final bounce secures the cluster by closing the PLAINTEXT port. 
 
-```properties
+```java-properties
 listeners=SSL://broker1:9092,SASL_SSL://broker1:9093
 security.inter.broker.protocol=SSL
 ```