<p>A few things here...</p>
<ol>
<li>Removing an IP address has nothing to do with security.  Every hacker tool on the planet will happily enumerate IPs whether or not you give them out.  So, you can leave the IP there and do the right thing security wise.</li>
<li>So, per the above, host everything with https:// and proper user-name/password/api token/etc auth.</li>
<li>Allowing &quot;all of internet&quot; inbound is a bad idea in most cases.</li>
<li>If the main thing talking to your instance is another EC2, you can have a security group for each EC2 and you an reference one security group in the other one (rather than a specific IP).  This is safer and lets you forget about the IP addresses themselves as the security group linking will still work fine even if the IPs change.</li>
</ol>

CC BY-SA 4.0
2022-07-19T14:50:13.813Z
2022-07-19T14:50:13.813Z
John Humphreys
<p>I've setup own gitlab server on AWS EC2 Instance based on this image - <a href="https://aws.amazon.com/marketplace/pp/prodview-w6ykryurkesjq?ref_=aws-mp-console-subscription-detail" rel="nofollow noreferrer">https://aws.amazon.com/marketplace/pp/prodview-w6ykryurkesjq?ref_=aws-mp-console-subscription-detail</a> and assign Elastic IP for this instance.</p>
<p>I've prepared some pipeline for repository and getting error (after push and check pipeline status):</p>
<pre><code>Running with gitlab-runner 14.3.2 (e0218c92)
  on [PRIVATE IP ADDRESS] JA-qzGJG
Preparing the &quot;docker&quot; executor
Using Docker executor with image node:latest ...
Pulling docker image node:latest ...
Using docker image sha256:c4fbd63932640bbb14c76f80c5b53daf8f01cc1f011d260d07f35bb6874c0c30 for node:latest with digest node@sha256:fec9ab31c9d46ad952abed8119b71e01e995975bd7b580f07b249e803d306dbe ...
Preparing environment
00:02
Running on [RUNNER_NAME] via [PRIVATE IP ADDRESS]...
Getting source from Git repository
02:11
Fetching changes with git depth set to 50...
Reinitialized existing Git repository in /builds/logifiles/queue/.git/
fatal: unable to access 'http://ec2-[OLD_EC2_INSTANCE_IP_ADDRESS].compute-1.amazonaws.com/logifiles/queue.git/': Failed to connect to ec2-[OLD_EC2_INSTANCE_IP_ADDRESS].compute-1.amazonaws.com port 80 after 129988 ms: Operation timed out
ERROR: Job failed: exit code 1
</code></pre>
<p>I remove IP addreses, due security reasons.
My pipelines for repository:</p>
<pre><code>image: node:latest
cache:
  paths:
    - node_modules/
stages:
  - dist
before_script:
  - npm i
dist:
  stage: dist
  script:
    - echo &quot;//${CI_SERVER_HOST}/api/v4/projects/${CI_PROJECT_ID}/packages/npm/:_authToken=${CI_JOB_TOKEN}&quot;&gt;.npmrc
    - npm publish
  rules:
    - if: $CI_COMMIT_BRANCH == &quot;master&quot;
</code></pre>
<p>So how should i properly handle it ? How to change IP address in pipeline or set different url for gitlab, or maybe prepare some redirect from old ec2 instance domain to new one (from Elastic IP). Is there any other way how can i handle it ?</p>
<h3>Edit 1</h3>
<p>This is security group for inbound rules for ec2 instance:
<a href="https://i.sstatic.net/JGvqC.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/JGvqC.png" alt="enter image description here" /></a></p>

<amazon-web-services><gitlab><amazon-ec2><gitlab-ci-runner>
Gitlab (self hosted gitlab) pipeline fail when trying to fetch repository
Marcin Warzybok
# Gitlab (self hosted gitlab) pipeline fail when trying to fetch repository

(Asked by: username_0 on 2021-10-14)

I've setup own gitlab server on AWS EC2 Instance based on this image - https://aws.amazon.com/marketplace/pp/prodview-w6ykryurkesjq?ref_=aws-mp-console-subscription-detail and assign Elastic IP for this instance.
I've prepared some pipeline for repository and getting error (after push and check pipeline status):
Running with gitlab-runner 14.3.2 (e0218c92)
  on [PRIVATE IP ADDRESS] JA-qzGJG
Preparing the "docker" executor
Using Docker executor with image node:latest ...
Pulling docker image node:latest ...
Using docker image sha256:c4fbd63932640bbb14c76f80c5b53daf8f01cc1f011d260d07f35bb6874c0c30 for node:latest with digest node@sha256:fec9ab31c9d46ad952abed8119b71e01e995975bd7b580f07b249e803d306dbe ...
Preparing environment
00:02
Running on [RUNNER_NAME] via [PRIVATE IP ADDRESS]...
Getting source from Git repository
02:11
Fetching changes with git depth set to 50...
Reinitialized existing Git repository in /builds/logifiles/queue/.git/
fatal: unable to access 'http://ec2-[OLD_EC2_INSTANCE_IP_ADDRESS].compute-1.amazonaws.com/logifiles/queue.git/': Failed to connect to ec2-[OLD_EC2_INSTANCE_IP_ADDRESS].compute-1.amazonaws.com port 80 after 129988 ms: Operation timed out
ERROR: Job failed: exit code 1

I remove IP addreses, due security reasons.
My pipelines for repository:
image: node:latest
cache:
  paths:
    - node_modules/
stages:
  - dist
before_script:
  - npm i
dist:
  stage: dist
  script:
    - echo "//${CI_SERVER_HOST}/api/v4/projects/${CI_PROJECT_ID}/packages/npm/:_authToken=${CI_JOB_TOKEN}">.npmrc
    - npm publish
  rules:
    - if: $CI_COMMIT_BRANCH == "master"

So how should i properly handle it ? How to change IP address in pipeline or set different url for gitlab, or maybe prepare some redirect from old ec2 instance domain to new one (from Elastic IP). Is there any other way how can i handle it ?
Edit 1
This is security group for inbound rules for ec2 instance:

**Tags:** amazon-web-services, gitlab, amazon-ec2, gitlab-ci-runner


---

## 1 answers

### Answer by username_1 on 2022-07-19. Score: 0

A few things here...

1. Removing an IP address has nothing to do with security. Every hacker tool on the planet will happily enumerate IPs whether or not you give them out. So, you can leave the IP there and do the right thing security wise.
2. So, per the above, host everything with https:// and proper user-name/password/api token/etc auth.
3. Allowing "all of internet" inbound is a bad idea in most cases.
4. If the main thing talking to your instance is another EC2, you can have a security group for each EC2 and you an reference one security group in the other one (rather than a specific IP). This is safer and lets you forget about the IP addresses themselves as the security group linking will still work fine even if the IPs change.


---

