When using Confluent Cloud, two distinct interactions will need authentication:
For users, the simplest way to access Confluent Cloud is via email address. While this method works great for a small set of users, most organizations will want to use single sign-on (SSO).
SSO provides a single entry point for users to log into any of the applications they have access to.
You are probably already familiar with SSO and have used identity providers (IPs) such as Okta, Active Directory, or Google accounts for authentication. The benefit of SSO is that it enables a central and consistent policy layer for multi-factor authentication (MFA), password enforcement, and terminating user access. The only requirement for this method is that your IP must use Security Assertion Markup Language (SAML).
For authenticating applications or services, there are two options: API keys or connecting your applications via OAuth.
You can get an API key through the Confluent CLI or the web interface. Each API key consists of a key and secret. There are two types of API keys you can use:
Resource-specific API keys give access to individual resources in a particular environment. An environment is a collection of Kafka clusters and deployed components such as Connect, ksqlDB, and Schema Registry. An organization can contain multiple environments. You may have different environments for different departments or teams, for example, all belonging to the same organization.
The second type of API keys, Cloud API keys, grant management access to the entire organization's Confluent Cloud instance, including all environments.
If you plan on using API keys, keep in mind:
When you rotate API keys, it is recommended you perform the steps in the following order:
Always make sure to use audit logs to track the usage of API keys.
As previously mentioned, OAuth is the other way to provide access to your applications and services.
OAuth allows you to access your resources and data without having to share or store user credentials. It’s built off cryptographically signed access tokens that allow your application or service to authenticate.
There are a few advantages to using OAuth for authentication:
OAuth is a cloud-native authentication solution. Most companies already employ an OAuth solution for other cloud resources they use for authentication/identity management.
OAuth provides centralized identity management. This is advantageous because system administrators have only one place to manage authentication for all their systems rather than having to create and manage credentials, or set up a sync system, for each independent service in their organization.
OAuth is an industry standard for providing authentication. If your organization provides a large number of service accounts, or there are a large number of applications accessing Confluent Cloud, you may run out of API keys. OAuth allows you to scale to thousands of identities and credentials, making sure that your applications only have the access they are supposed to have.
OAuth uses identity pools to map groups of identities to your role-based access control or access control list (ACL) policies. For example, let’s say you have a group of applications that all need access to the same cluster or Kafka topic. Rather than giving each application individual access, or controlling access on a per-application basis, you can create an identity pool, and use an identity pool filter to map each application identity to this identity pool. Then, using RBAC or ACL policies you can control permissions for the pool.
There are a few things to keep in mind if you plan to use OAuth:
Whether you use API keys or OAuth, we highly recommend using RBAC for authorization, something that we’ll look at in the next module.
We will only share developer content and updates, including notifications when new content is added. We will never send you sales emails. 🙂 By subscribing, you understand we will process your personal information in accordance with our Privacy Statement.