GitLab Azure Ad
You set up gitlab azure ad by linking your directory app to your code host. This link lets your team log in with one main work account. Most teams start by turning on single sign-on for all users. They map broad directory groups to default project roles inside the app. This fast setup saves time for system admins during user onboarding. Still, broad roles often give developers too much power across all code repos. A user might get write permissions on production scripts by mistake. How the gi
Azure RBAC + GitLab CI Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up gitlab azure ad by linking your directory app to your code host. This link lets your team log in with one main work account.
Most teams start by turning on single sign-on for all users. They map broad directory groups to default project roles inside the app. This fast setup saves time for system admins during user onboarding. Still, broad roles often give developers too much power across all code repos. A user might get write permissions on production scripts by mistake.
How the gitlab azure ad link works
The link between your code tool and directory relies on standard web login flows. First, an admin registers a new enterprise app inside the Microsoft cloud portal. Next, the admin copies the unique trust keys into the code host settings. Both systems now share a trust bond for user login checks.
When a developer tries to log in, the code tool sends them to Microsoft. The directory checks their password and runs a multi-factor phone check. After a pass, the directory sends a signed token back to the code host. This token holds the user identity and a list of group names.
Teams also use automated user sync to manage accounts over time. When a person joins the company, the directory creates their code account right away. Group links then place that user into the right project teams. When that person leaves the firm, the directory blocks their login access fast. This setup keeps your user list clean without manual admin work.
What directory login solves and what it misses
A directory link solves the problem of scattered user passwords and orphan accounts. Admins have one central place to check who can enter the code platform. Auditors can read login logs to see when a developer entered the system. Group sync ensures that role changes in human resources match team groups.
Still, directory login only checks who a user is at the front door. It does not control what happens after the user starts a work session. Once inside, a developer or build job often holds broad static keys. These keys let pipelines run changes against live databases and cloud servers.
Azure RBAC + GitLab CI Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
The directory cannot see individual database queries or server commands in flight. If a build script runs a bad delete command, the directory will not stop it. Also, raw data from test runs can expose sensitive fields in job logs. Directory roles alone cannot rewrite emails, phone numbers, or card numbers in results. Teams need controls that check every command and mask sensitive data at runtime.
Managing build runners and service accounts
Human users are only half of the security picture in a code platform. Automated build runners also need tight rules when they run deployment jobs. Many teams give runners static keys that never expire. If an attacker steals a repo key, they can read production data.
A better pattern uses short trust tokens between the runner and the cloud. The runner asks the directory for a fresh token at the start of a job. That token dies as soon as the build job finishes its work. Even with short tokens, the runner still has full role power during the run. You still need a way to inspect each command the runner sends out.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
How do we map directory groups to project roles?
You link directory group IDs to specific team groups inside your code host settings. When a user logs in, the system reads their group list and sets their role.
What happens when we remove a user from the directory?
If you turn on automated user sync, the code host blocks the account fast. The user cannot log in through the web page or use old tokens.
Can directory login protect databases used inside build pipelines?
No, directory login only controls who can enter the code app itself. It does not inspect SQL queries or mask national IDs during a build run.