Welcome back. In this lecture, we'll now review some of the more important account-level Bitbucket configuration settings. Do keep in mind that each repository within a Bitbucket account also has its own repository-specific settings to also consider. We won't cover off all of the available account-level settings. Again, many are self-explanatory. However, we will go over and demonstrate some of the more unfamiliar but nevertheless important ones. For the account-level settings, we will cover user groups, app passwords, SSH keys, two-step verification, and finally, integrations and features. User groups allows you to set up any number of groups into which you can then add Bitbucket users. Next, you grant permissions and attach them to a group, with all the members of the group inheriting those permissions. In the example presented here, user Ann Smith, who belongs to the BuildAndRelease group, has write permissions to all repositories within the account. However, John Brown, who belongs to the Engineers group, only has read permissions to all repositories within the same account.

 Again, permissions can be adjusted down at the repository level and take precedence over the account level permissions. Creating an app password results in Bitbucket generating an unguessable substitute password which is presented just once to the administrator. This app password is scoped and limited to a set of permissions defined by you, the administrator. A motivation for creating and using an app password is when you're in need of authenticating to, and making calls against, the Bitbucket API. App passwords are designed to not require two-step verification if it has been enabled at the account level, allowing you to still integrate third-party tools and all automation scripts against your Bitbucket repositories. We'll provide a demonstration of this capability later on. SSH keys allows you to add keys to enable you to authenticate to your Bitbucket repositories using the SSH protocol. SSH keys are more secure, reducing the risk of accidentally exposing usernames and or passwords, which are required credentials when working with HTTPS to communicate between your local system and the Bitbucket cloud. SSH keys can be configured at the account level as seen here and additionally at the repository level. SSH keys configured at the account level are applied to all repositories within the account.

 Repository-defined SSH keys restrict access to just that repository in which the SSH key was added to. Two-step verification or second-factor authentication when enabled requires the user to authenticate with not only the username and password, with the password being the first factor or the something they know part, followed by a requirement for a second factor which must be the something in the position part. The something in the position part is often a rotating one-time password or OTP. This 2SV sequence protects the user from having their password being captured by a keylogger, et cetera. We will provide a demonstration later on in which we sign up and enroll for 2SV. Integrations and features allows you to find and integrate with other third-party provider solutions, providing your team with additional access to other code quality tools. And of which, when enabled, are embedded and presented directly within the Bitbucket web console itself. BitBucket supports storing very large files using Git LFS. Git LFS is an extension to the standard Git protocol, jointly developed between Atlassian and GitHub. With Git LFS, large binary files are stored remotely and externally to the repository itself. Instead, pointers are used in their place. This has the advantage of dramatically improving the time it takes to download and clone a repository. Okay, that completes this lecture on managing Bitbucket at the account level. Next up are several hands-on demonstrations including several of the various account-level management activities we have just covered. But for now, go ahead and close this lecture and we'll see you shortly in the next one.