Common Questions:
Q1: Out of curiosity, how is the devsecops-box machine always able to ssh into prod for example? I killed the ssh-agent on the devsecops-box and it can still auth to prod
A: It's because we have designed the lab to store the production machine by default, and as long as the private key is there, you will be able to SSH into the production machine. In our DevSecOps Box, there is a private key stored at /root/.ssh/id_rsa. This key is being used to SSH into the production machine If you remove that private key from /root/.ssh/, you will no longer be able to SSH into the production machine.
Q2: Where is the configuration file that points my devsecops-box to the IP and the correct SSH private key to use when authenticating?
A: Upon the initial authentication, the system will prompt for host verification. During this process, SSH determines which private key corresponds to a given server. The remote machine will then verify if the keys match. While this may not be a configured setting, it reflects the underlying mechanism of how SSH operates. To enable SSH access, the public key from our machine (DevSecOps Box) must be added to the authorized keys on the production machine. This step ensures that the production machine can recognize and authorize the machine attempting to establish an SSH connection.
Q3: How does my devsecops-box know the correct private key path for that machine? There must be a configuration somewhere that states for this host use this key, etc
A: To set up SSH access, you need to generate your own key pair, consisting of a public and a private key. After generating the keys, you should copy your public key to the remote machine and place it within the /root/.ssh/authorized_keys file on that machine. This file is used to determine whether the incoming machine's key is correct and if an SSH connection can be established
Q4: If I am using a private key to SSH into a remote host. AFAIK, you need to use -i /path/to/private_key and since we are not doing that I am assuming there is some configuration somewhere on the devsecops-box that does something equivalent, so that I don't need to use the -i flag.
A: No configuration is needed, it is the default behavior to pick up the SSH key at /root/.ssh/id_rsa. Otherwise, as you mentioned, we would need to use -i if the private key is stored elsewhere in our system, it's not always /root, but your home directory Since our lab is using root by default, that's why I mentioned /root
Q5: In the Harden Machines in Ci/CD pipelines lab in the IaC section, why did not we just get the current docker user and copy the private key into his ssh directory instead of doing ssh-add? is there a difference between both things?
A: In CI/CD pipeline we use it to avoid prompt during SSH authentication
Even we have added into ssh directory, for initial connection it will ask the prompt every time and we need to bypass it inside the CI/CD pipeline. You can try by remove it and see what will happens:
stage: prod
image: willhallonline/ansible:2.9-ubuntu-18.04
before_script:
- mkdir -p ~/.ssh
- echo "$DEPLOYMENT_SERVER_SSH_PRIVKEY" | tr -d '\r' > ~/.ssh/id_rsa
- chmod 600 ~/.ssh/id_rsa
- eval "$(ssh-agent -s)"
Q5: What is the purpose of ssh-add?
A: The purpose of ssh-add in the script is to add private keys to the SSH authentication agent. This allows the user to use their private key for authentication without having to enter the passphrase every time they connect to a remote server using SSH. By adding the private key to the SSH agent, the user can securely authenticate to remote servers without exposing the private key or entering the passphrase repeatedly. You might find these helpful: https://superuser.com/a/784664
Q6: Can you explain what the list of items are in the general structure of the playbook.yaml file and when to add a hyphen vs not?
A: In YAML, list items are denoted by a hyphen -. The hyphen signifies that the items that follow (indented under the hyphen) are part of a list. That's why you see a - before the name. It indicates that the set of name, hosts, remote_user, become, roles, etc is considered one unit or list item. For a basic example, Ansible provides official documentation. Please take a look at this official documentation: https://docs.ansible.com/ansible/latest/reference_appendices/YAMLSyntax.html#yaml-basics
Q7: What item is name and why does hosts not get a hyphen? Similarly, why does roles get hyphenated?
A: It's answered by this example here: https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_intro.html
This is the structure of an Ansible playbook for your understanding:
**Play Section**:
- name: Example playbook to install Terraform using Ansible role.
hosts: prod
remote_user: root
become: yes
A play is an ordered set of tasks that should be run on hosts selected from an inventory. In this case, the play is named "Example playbook to install Terraform using Ansible role."
**Role from Ansible Galaxy Section**:
roles:
- secfigo.terraform
This is not a regular command; instead, we use an Ansible Galaxy role as an example, which contains some predefined **tasks**.
**Tasks Section**:
tasks:
- name: ensure firewalld is at the latest version
apt:
name: firewalls
This section defines the steps of your required jobs in Ansible.
Q8: when the gitlab-ci.yaml file is coded, run. Do we write the gitlab.yaml file during the code phase and run the file during the build process?
A: We need to create a .gitlab-ci.yml file either at the beginning or at the end of the coding phase. If we add it at the end, it will not automatically deploy the configuration to the server. Alternatively, we can define specific rules to prevent changes from being applied to the server automatically
Q9: Why did you choose to copy the private SSH key over with the authorized_keys on the deployment server?
A: This is part of an SSH set up. You set up the public key in the authorized_keys directory of a target server to mention that this public key (and the owner who has the corresponding private key) can connect to the target server. This is why we consistently add the private key into GitLab variables. When you attempt to SSH from the DevSecOps Box to any other machine, no further setup is required—it will connect as intended, thanks to the pre-configured private keys for each remote machine.
But if you would like to test it yourself, please try the following:
-
You need to provide the SSH private key corresponding to the public key that you have added to the remote machine, let's call it machine A, in order to connect.
-
You will use your own private key for the connection, so you only need to add your public key to the remote machine
Q10: Is it possible to add the Gitlab runner public key to the production authorized_keys file? That way, we won't have to copy any private keys.
A: it's possible to add Gitlab runner's public key to the production server's authorized_keys file, this is a standard practice. Please note that our machine is already pre-configured so that it can communicate to each other without further settings.
Q11: How does the Inspec tool work? Does the container get spun up with the image and then the SSH connection get established from within the container to the target machine?
A: Your statement is correct, a container that has InSpec installed performs the same function as a native tool installed on the host. It establishes an SSH connection to the target machine, and by default, it uses the SSH key located at /home/user/.ssh. However, if the private key is in a different location, you might need to specify the path using the option -i /path/to/custom/privkey. InSpec will then use this specified private key for authentication
Q12: If the repo exists on Gitlab , which location does repository reside?, I want to see in the host machine itself rather on the GUI.
A: This is what the directory looks like. Though you will need to tree command to see the directory inside. It won’t show the same as the GUI due to the git repository mechanism. https://docs.gitlab.com/ee/administration/repository_storage_paths.html#hashed-storage