Configure ACLs

The following page provides a management guide for ACLs (Access Control Lists). This document provides instructions on how to enable, disable, create, and delete ACLs for your WarpStream clusters.

Prerequisites

Before you begin, ensure you have administrative access to the WarpStream console and are familiar with the basic concepts of ACLs.

The current version of ACLs only supports the SASL authentication method. Review Enable Agent Authentication for more information.

Important: ACLs are only compatible with Agent version 526 and above. Make sure you use a compatible agent version, if your cluster has self-hosted agents.

Important considerations

There are a few things to keep in mind when using ACLs, which are covered below.

ACL Principal

ACLs operate using Principals, which are entities capable of being authenticated by the Authorizer. In the context of WarpStream agents, clients authenticate as a specific principal by utilizing SASL/PLAIN authentication. With this method, the principal is identified by the username assigned during credential creation, which is prefixed with ccun_.

Super users

In the context of ACLs, a 'superuser' is a specially designated user who possesses elevated privileges. Superusers are granted overarching access rights, allowing them to bypass standard ACL restrictions. This includes unrestricted abilities to create, modify, or delete resources, and to manage access controls for other users. In Warpstream you can create super users through the credentials, as explained atGenerating Credentials

Caching of ACLs

For performance reasons, ACLs are cached, so changes to ACLs may take between 30 seconds to 1 minute to take effect. Plan accordingly when updating ACLs in a production environment to ensure a smooth transition.

allow.everyone.if.no.acl.found

Warpstream does not implement the allow.everyone.if.no.acl.found Kafka configuration, because:

  1. It's not safe for production environments.

  2. You can get the equivalent (and safer) behaviour by simply using Super users, who are authorized to access everything.

Enabling and Disabling ACLs

Warning

Before enabling ACLs, be aware that improper configurations may lead to denied access for producers and consumers. Make sure to configure ACLs correctly to avoid any disruption of service.

To Enable ACLs

  1. Navigate to the WarpStream console.

  2. Select the desired Virtual Cluster, for example vcn_default.

  3. Click on the ACLs tab.

  4. You will see the ACLs: Disabled status label if ACLs are currently disabled.

  5. Click on the Enable ACLs button to change its status to Enabled.

To Disable ACLs

  1. Follow the same steps to navigate to the ACLs tab of your Virtual Cluster.

  2. If ACLs are enabled, you will see the ACLs: Enabled status label.

  3. Click on the Disable ACLs button to turn off ACLs for the cluster.

Enable/Disbable Using the HTTP API

Alternatively, you can switch ACLs on and off using the HTTP APIs, which is a convenient alternative to doing it through the console UI. Refer toDescribeConfiguration and UpdateConfiguration for details.

Generating Credentials

To interact with WarpsSream clusters, you need to generate credentials:

  1. Within the WarpStream console, navigate to the Credentials tab of your Virtual Cluster.

  2. Click on Generate Credentials.

  3. Provide a name for the credentials.

  4. If necessary, enable Super User for broader permissions.

    • Important: If a resource has no associated ACLs, then only superusers can access that resource.

  5. Click Generate Credentials. The credentials will be displayed for you to use with the CLI.

Important: Credentials are shown only once. Store them securely.

Managing ACLs via Kafka API

To manage ACLs via the Kafka API, use the Kafka Admin API with appropriate Kafka credentials.

Create an ACL

To create an ACL, use the createAcls method with the required ACL details:

_, err = admin.CreateACLs(
	context.Background(),
	kafka.ACLBindings{{
		Type:                kafka.ResourceTopic,
		Name:                "topic_name",
		ResourcePatternType: kafka.ResourcePatternTypeLiteral,
		Principal:           "User:<credential_username>",
		Host:                "*", // Request can come from any host.
		Operation:           kafka.ACLOperationWrite,
		PermissionType:      kafka.ACLPermissionTypeAllow,
	}},
)
if err != nil {
	fmt.Printf("Failed to create ACLs: %s\n", err.Error())
	os.Exit(1)
}

Delete an ACL

To delete an ACL, use the deleteAcls method with a filter matching the ACL you wish to remove:

_, err = admin.DeleteACLs(
	context.Background(),
	kafka.ACLBindingFilters{{
		Type:                kafka.ResourceTopic,
		Name:                "topic_name",
		ResourcePatternType: kafka.ResourcePatternTypeLiteral,
		Principal:           "User:<credential_username>",
		Host:                "*",
		Operation:           kafka.ACLOperationWrite,
		PermissionType:      kafka.ACLPermissionTypeAllow,
	}},
)
if err != nil {
	fmt.Printf("Failed to delete ACLs: %s\n", err)
	os.Exit(1)
}

The examples above use the librdkafka package from Go. You can also try the bin/kafka-acls.sh script from Apache Kafka®'s official binary release for more hands-on experience:

bin/kafka-acls.sh --bootstrap-server localhost:9092 --remove --allow-principal User:<credential_username> --allow-principal User:Alice --allow-host 198.51.100.0 --allow-host 198.51.100.1 --operation Read --operation Write --topic Test-topic
bin/kafka-acls.sh --bootstrap-server localhost:9092 --add --allow-principal User:Bob --allow-principal User:<credential_username> --allow-host 198.51.100.0 --allow-host 198.51.100.1 --operation Read --operation Write --topic Test-topic

Last updated

Logo

Apache, Apache Kafka, Kafka, and associated open source project names are trademarks of the Apache Software Foundation. Kinesis is a trademark of Amazon Web Services.