Gitea mirroring security requirements

[JimMadge]

We are aiming to use the internal Gitea instance to mirror external git repositories in a read only manner.

We need to investigate how to do this in a secure way that,

• Does not allow data egreess (e.g. allowing pushing to external git repositories)
• Enables admins to review/approve/revoke mirrors (e.g. we are probably not comfortable with users being able to add access to arbitrary repositories themselves)

We should design an architecture/configuration that supports these requirements.

[JimMadge]

Gitea can set up pull repositories where you are not able to push back to the "original" repository.

The repository is periodically synced and can be synced ad-hoc

• How often is periodic sync? Can we configure that?
• Who can start an ad-hoc sync?

[JimMadge]

With Gitea is is possible to enable browsing repositories without signing in (this is enabled by default).

This means we could have a Gitea instance which users are not expected to authenticate with, to browse the read only mirrors. (I assume that would mean an additional instance, which might be a little confusing, but we could use sensible domain names/theming to differentiate them)

An authenticated user can create mirrors

When not authenticated, you can only browse

Configuration,

• Disable self-registration: True
• Show register button: False
• Enable OpenID self-regirstration/authentication: False
• Require sign-in to view pages: False

[JimMadge]

@craddm @jemrobinson does a two Gitea instance solution (one for internal development, one for mirrors) sounds good to you?

[craddm]

Yes, and giving them sensible domain names sounds good (could be as simple as external.* and internal.*)

[jemrobinson]

Can you stop a non-authenticated user from registering? I wonder whether a simpler solution is to do what we used to do with package mirrors:

• external server: able to access the internet, not accessible by users
• internal server: not able to access the internet, accessible by users

with mirroring rules set up from internal to external AND external to GitHub/wherever.

[JimMadge]

Can you stop a non-authenticated user from registering?

Yes, you can disable registration methods so that only an admin could create new users. Similar to how Nexus works.

I think this idea is simpler, less networking configuration and you would only need to create one repository migration.

[jemrobinson]

I'm still a bit nervous about allowing the user-accessible Gitea server to have unrestricted outgoing access to GitHub/GitLab/whatever. How can we convince ourselves that users couldn't (a) get admin rights on this and/or (b) use it as an egress pathway?

[JimMadge]

Yes, I think those are good questions. If we aren't confident, then something like an airgaped set of Gitea instances should work.

Luckily, I thin a lot of the infrastructure we need is the same in either case. We still want two Gitea instances and a method for creating read only mirrors to an instance inside an SRE.

AFAIK, what I proposed would give users inside the TRE no way to register an account. They could however authenticate if they had the credentials of a valid account. If they did that, I think it would be an easy egress pathway as you could create a push mirror to an external repository.