terraform-aws-access/notes/security_groups.md

Security groups

specific ip

• this module was made with the idea that it would be used in creating an rke2 node
  • I think the module was too specific in a few places
    • I don't think the module should include access for CI or any one entity to the project
      • this infers the ssh key and specific ips added to security groups should de removed
• how do we install or manage things when we create them?
• any object further down the line will be able to add a new security group to give access to that object
  • we expect to give a project level entry point in the loadbalancer with an eip
  • the security group types should reflect how we want to expose the load balancer
• how does a user access their infrastructure?
  • any user should be able to add themselves to a project without affecting any of the other parts of the project
    • an entity from outside the project could be some client or a user
    • a user might need an ssh key, adding them to a server that already exists would require something logging into the server and adding them
      • the "something" could be a CI runner, or it could be something like Vault
      • that something will need to be able to clean things up if the access changes
  • any client will need their IP added to the project (unless it is open to the internet)

add client module

• I think we have identified a new module to help manage a project

• the project_client module would have its own lifecycle, right?

• each client would have its own lifecycle

• maybe it doesn't need its own module?

• would a map of clients in this module work better?

• lets take a concrete example

  • adding the CI to a project is an important client because the CI will provision the basic needs of the servers
  • CI keys and IPs are ephemeral, so they need to be created and removed before and after contact
  • the CI will need:
    • its ip added to the load balancer to access services
    • a security group with its ip
      • allowing ingress to port 22 for ssh access
      • allowing ingress to port 6443 for kubernetes access
      • allowing ingress to port 443 for rancher access
    • this security group will need to be added to servers
      • the idea is not to add the security group to the load balancer
        • this is because once it has access to the servers it can access kubernetes directly from one of the control plane nodes
    • its ssh key added to servers to enable ssh access
  • the server access level of this indicates the need for separation of concerns
    • we don't want this module to manage servers because the expectation is that they don't exist yet when this is run
    • keeping this lenear progression helps users fit things in their head