Gitlab On premis Machine Active Directory

How to Use GitLab
1

Hi every 1…

Could any one confirm the industry best practice regarding GitLab server access?
I am not referring to GitLab web UI login — we already use Active Directory/LDAP for that.

My question is only about whether the GitLab VM itself should be joined to AD inorder to SSH into it for various admin activities.**
I prefer not to join the VM to AD for security reasons, and I would like to know if this aligns with common enterprise practice

Thanks in advance.

2

I would say there isn’t an industry best practice. You choose the method that suits your requirements. If you don’t want to use AD/LDAP, then don’t use it. People who tend to use AD/LDAP or other authentication methods, do so because they want a single place to control usernames and passwords. If you have AD/LDAP, why would you then create users manually across 50 other servers? You wouldn’t because it would be a big headache managing all of that.

If you add the servers to AD/LDAP or oauth or whatever, then you have a single place to create users and control access to all servers that you manage and maintain.

Again, if you don’t want to do it, then don’t. If you need flexibility and easily managing users, then you would use a solution like AD/LDAP, oauth or something else. And it doesn’t matter if the server is Gitlab, or some other application - the same logic applies.

3

Thanku

4

I agree.

Our servers (including the ones running GitLab components) are not connected to the company AD, while GitLab is.

We (the department that manages those servers) are strongly opposed to connect the servers to the AD, two main points:

  1. We already have automation for create users on the servers they need access to
  2. We don’t want to make login to the servers dependent on (the company running) the AD.
5

Basically what i wanted to point out was about trust among different dependent teams.
For example, assume that we have a GitLab primary instance running in one cloud, and a Geo-replica in another cloud (DR site). You can also imagine it as a single instance – the point is the same.

If the GitLab administrator (a single person) is responsible for performing GitLab application

upgrades and OS patching (including unattended upgrades, kernel rollback if required, dist-upgrade, etc.), then there is no need for additional user accounts for that purpose.

However, a separate user account is still required for security vulnerability scanning. These scans may be scheduled monthly or twice a month depending on the cloud/IaaS policies. They are usually done by Security VA Team using an account that needs sudo access on the VM. So, we may need to create user accounts for them.

My concern is not technical, but related to trust and cloud policies. I do not prefer to use Active Directory for this, because only one to three users need SSH access to the VM, but the real issue is the trust associated with those accounts.

The only disadvantage of not using Active Directory for SSH access to the GitLab servers is that we need to maintain two to four local user accounts with sudo access on both the primary GitLab server and the secondary GitLab server.

As @iwalker told , it applies to all .