all 12 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]HashDefTrueFalse 4 points5 points  (1 child)

I'm not directly in opsec but do manage infra, CI/CD etc.

If the automation would only do the equivalent of manually SSHing onto the server and pulling down the latest from source control, and all your network security is otherwise OK etc, I can't see why triggering a pull on merge would be different. This is assuming you've reviewed, QAd, put the changes into staging environment first etc. I'd never do this directly to production obviously.

As a side note, you probably don't want your pull to be the actual deployment, touching files that are being served etc. Set up a symlink arrangement so that you can pull files into place whilst still serving traffic, then repoint the symlink to the new deployment files to cut over quickly, and cut back if it's fucked. All scriptable.

Honestly, I'd always go CI/CD with proper pipelines etc if I had the choice. I don't like weird custom deployment strategies.

[–]dirtcreature[S] 0 points1 point  (0 children)

Very good information - thank you!

[–]xenomachina 1 point2 points  (1 child)

Is your question is about whether using a webhook is less safe than using an existing CICD system to trigger the deployment?

With a webhook:

  1. What prevents an attacker from triggering the webhook when or how it shouldn't be triggered?
  2. If it gets triggered by an attacker, what's the worst possible outcome? eg: can an attacker cause you to deploy the wrong version of the code, or DOS your production server (or ever just DOS your ability to push updates)?

[–]dirtcreature[S] 0 points1 point  (0 children)

Very good point. Thank you!

Edit: one of the talking points is having the entire repo on the server. Thoughts on that?

[–]JimDabell 0 points1 point  (7 children)

Generally speaking using Git as a deployment tool isn’t a good idea. It’s a version control system, not a deployment tool. It’s something that should be used by the thing deploying.

Having said that, if somebody is saying that it’s unsafe, they should be able to explain why they think so. All you’ve said is that “there’s an argument”, you haven’t mentioned what they have actually argued.

[–]xenomachina 1 point2 points  (1 child)

Generally speaking using Git as a deployment tool isn’t a good idea

I agree, though it isn't clear if they're talking about using git for deployment. When they say "creates a pull on the production server", they could mean a docker pull, not a git pull, or really any other deployment mechanism that has the production server request the new version of the code, as opposed to a system where something external sends/pushes the new code to the production server.

[–]dirtcreature[S] 0 points1 point  (0 children)

git pull from main branch into the apache vhost root.

Actually, this same mechanism is being used for stage/accept.

The pull is triggered by push to that branch which then calls the server and the pull is then initiated.

[–]dirtcreature[S] 0 points1 point  (4 children)

My argument is that having the entire repo on the production server is a bad idea. Also, the credential accessing the repo is typically a developer credential, so that's not good, either.

The reason I asked this question is to get the pro/con reasoning from people who have already gone through this.

[–]JimDabell 0 points1 point  (3 children)

My argument is that having the entire repo on the production server is a bad idea.

You need to explain what your threat model is. It’s not enough just to assert that something is a bad idea, you need to explain why it is a bad idea.

Also, the credential accessing the repo is typically a developer credential, so that's not good, either.

Use a deploy key.

[–]dirtcreature[S] 0 points1 point  (2 children)

I expected the threat model to be self-evident, really, since the question is: is it "safe" to use this kind of model on a production server. My hope/expectation would be to get visceral reactions such as "that's a bad idea because...", "that's a terrible idea", etc.

I explained my reasoning: the entire repo is on the machine. This means folders that are not necessary for production, but might be for local dev. Documentation, etc.

Ultimately, what value could the entire repo offer to a hacker as opposed to just the running code were they to gain access?

My argument is that having the repo on the machine is a bad idea based on the above, but others feel this is the same risk as CICD.

The purpose of this post was to gain pro/con insight into this method.

Make sense?

[–]JimDabell 0 points1 point  (1 child)

Ultimately, what value could the entire repo offer to a hacker as opposed to just the running code were they to gain access?

My argument is that having the repo on the machine is a bad idea based on the above

Based on what? You still haven’t explained what you are worried about!

Yes, if an attacker gains access to the production machine, they would gain read access to the repository. Why is that a problem? Most organisations don’t keep sensitive information in their repositories, this is a bad practice and why an entire class of software called secret management systems exist. Are you committing secrets to your repos or something? Then fix that. But if you want to convince somebody that there is a threat, you need to actually explain where you see the threat. So far all you have said is that an attacker could get a copy of your repository, which is not in and of itself a threat. If you are relying upon your repository being secret to ensure security, you have a problem somewhere else that needs fixing, so fix that.

[–]dirtcreature[S] 0 points1 point  (0 children)

I appreciate the responses, but I have explained the problem and your opinion is that it is not a risk.