When you deploy your agent, you need to make sure it has the right permissions to access only the data it needs. In this lesson, you'll learn what Databricks identity you need to assign to your agent so that it has the appropriate permissions. All right, let's get to it. There are three main types of identities for Databricks. There are your users. This is your user identities recognized by Databricks and they're represented by your email address. Service principals are to be used with jobs, automated tools, and systems such as scripts, apps, and CI/CD platforms. And then you have your groups. So groups simplify identity management, making it easier to assign access to workspaces, data, and other securable objects. So your groups can have sets of users, they can have service principals all assigned to them, and that way you can just give access to a group if you're giving access to data, to models, anything you want to be able to grant permissions on. You can give it access to this entire group composed of users and service principals. For example, if you make a group of developers and they need broad access. you can grant it easily instead of doing it one by one. There are also administrative roles that can manage Databricks identities. So this is your Account Admin, the highest level. They can add users, add service principals, and groups to accounts and assign admin roles. Workspace Admins add users and service principals to accounts, and they can grant access to workspaces. So your Group Managers, those groups we just talked about, can manage the permissions within that group and assign group manager roles. And then you have your Service Principal Managers, so they manage the roles on those service principals. And those are identities for users, but what about identity management for agents? It's a challenge because an agent needs their own identity. An agent needs to run automated tasks and it needs access to data in order to do so. and using a human admin credential will create security and audit risk. So they need consistent identity regardless of who triggers the agent. A solution to this is by creating a service principal so that when you run an agent, you run it with the credentials of a service principal. So you'd first create this dedicated service principal for each agent. You'd grant minimum required Unity Catalog permissions for that service principal, or if that service principal is in a group, make sure the permissions match up. And then you deploy the agent with specific identity context. The authentication options for agents during deployments are one, automatic authentication passthrough or system authentication. So the agent service principal gets automatic access to declared resources. So this means it's the same identity regardless of who calls it. It has managed credentials automatically. And this is most common if you're building an agent as a POC or as a demo. Two, On-Behalf-of-User Authentication. So agents use the end user's credentials, so has the caller's identity. It's good for user specific sensitive data access, and this requires specific API scopes. If you need to validate your identity and you can only be a real human user in order to do that, you would be able to validate that with the caller's identity. So that's the on behalf of user authentication. And the third is manual authentication. So this is where you have a pre-created service principal with specific permissions. and what some orgs refer to as CENTRALIZED identity management. This is very common for companies that put a lot of systems into production because there's no on-the-fly service principal creation. And for this lab, since it's what we see very commonly for models in production and now for what we're seeing agents going into production use is Manual Authentication. So we are going to pre-create the service principal with specific permissions, and this will create a CENTRALIZED identity management so that we can deploy the agent with the credentials of the service principal. And you'll see that in the following labs. With Manual Authentication, we are going to first in lab one create the service principal. We're also going to create a group of developers and add the service principal to that group. We are going to make sure that group has very specific permissions so that when we develop the agent in lab two and deploy the agent in lab three, we are going to end up deploying the agent with the credentials of the service principal. Before we dive into this lab, if you'd like to follow along, you can create a Databricks free edition account and follow along with me on the lab steps. When you create a Databricks free edition account, you will have both admin privileges, so account admin as well as workspace admin. But just so you know, the account admin console is locked. So you won't have account admin privileges, and this is just because it is a free edition. Now let's get started.
