Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: add what to do in case if things are compromied

Table of Contents

Infrastructure Security

Basic

...

Security Principals

  • Access to all project instances, running ONAP, Kubernetes, openstack etc, shall go through secured jumphost/admin servers
    • This includes but not limited to ssh, http(s) and so on. For http(s) access, port forwarding/tunneling through jumphost can be employed.
  • The instances shall not have direct ssh access from anywhere but jumphost/admin servers
  • The instances shall be put in right/existing security groups depending on the purpose and that have only the required ports open and never into default security group
  • If new rules are required to be added to the existing security groups or new security groups need to be created, this shall only be done in a controlled manner by submitting a ticket to Nordix JIRA, Infra project
  • Everyone shall have and use their own accounts on admin/jumphost with only key based authentication - no shared keys
  • If access to development instances are required, everyone shall use their own ssh key to access them
  • Access to the OpenStack API shall be given on a need basis and a record of this access shall be kept
  • Access to the CityControl panel shall be given on a need basis and a record of this access shall be kept
  • People with CityControlPanel access shall not share their credentials with others
  • People with OpenStack API access shall not share their credentials/openrc files with others
  • All access requests including but not limited to SSH shall be done on Nordix JIRA, Infra project
  • Infrastructure shall automatically be scanned for potential issues such as checking security groups, operating system vulnerabilities, user access and so on
  • <addme>

What If

The resources you use are compromised

  • If the resources such as instances you created on Nordix Public Cloud Tenants are compromised, it is possible that the stacks you installed on them such as Kubernetes could be compromised as well
  • Remove all access to the instances in your project on the tenant you are working on to block both incoming and outgoing traffic as soon as possible. You can do this by removing associated security groups from the instances.
  • The reason to cut the access for all the instances is that some of the attacks are contagious and it is possible that all the instances are infected so an analysis needs to be done in your project to see the scale of the problem.
  • Contact Infra Core Team privately and discuss the issue with them. Never have this type of conversations on public maillists or IRC channels.
  • Do not remove or turn off the instances without consulting the Infra Core Team first as it is possible that the attackers left traces of what they have done on the instances and logs could contain valuable information to help us with further investigation and action.
  • Once the analysis is done, root cause is identified, and required actions are taken, the instances can be removed.
  • On top of the damages security incidents cause both for us and others, you should also expect at least 2 days to recover and go back to day to day work so everyone must be security conscious to begin with to prevent this happening to you or your teammates.

Your SSH keys are stolen

  • Remove all access to the instances in your project on the tenant you are working on to block both incoming and outgoing traffic as soon as possible. You can do this by removing associated security groups from the instances.
  • Once the access is removed, you can place the instance to a new security group with an IP you trust in order to login to the instance to take backup of your data. It is probably faster to remove compromised instance and start fresh on a new one as investigation of what the attacker did and cleaning it up would take more time than starting on a new instance. Also you might never be sure about if you cleaned it up enough.
  • Contact Infra Core Team privately if the stolen ssh keys are used for accessing instances created on Nordix Tenants.
  • Generate a new SSH keypair for your personal use, lock its filesystem access properly, and never share.
  • Do not use stolen SSH keypair again.

You shared your password accidentially

  • Immediately reset your password on the system you use it and contact Infra Core Team privately if the compromised account is used for Nordix Services
  • Never use the same password on multiple systems

<addme>

Code Security Checks

Relevant information regarding scanning code that's about to be committed to git repositories and catching potential security issues like

...