Use Nobus Identity Service to
create, distribute, change, and revoke Nobus access credentials.
A credential is a
data that confirms the identity of the user.
(It could be a user name and password, user name and API key,
or an authentication token that the Identity service provides).
Lock Away Your Nobus Account Root User Access Keys
You use an access key (an access key ID and secret access key) to make programmatic
requests to Nobus. However, do not use your Nobus account root user access key. The access
key for your
Nobus account root user gives full access to all your resources for all Nobus services.
You cannot reduce the permissions associated with your Nobus account
root user
access key.
Therefore, protect your root user access key like you would your credit card numbers
or any other sensitive secret. Here are some ways to do that:
-
You are adviced to use your account email address and password to sign
in to the Nobus Management Console and create a
user for yourself with administrative permissions.
-
Use a strong password to help protect account-level access to the Nobus Management Console.
-
Don't share your Nobus account root user password or access keys with anyone.
It must be kept private.
Create Individual Users
Don't use your Nobus account root user credentials to access Nobus, and don't give your
credentials to anyone else. Instead, create individual users for anyone who needs access
to your Nobus account. Create an user for yourself as well, give that user administrative
permissions, and use that user for all your work. F
By creating individual users for people accessing your account, you can give each
user a unique set of security credentials. You can also grant different permissions
to
each user. If necessary, you can change or revoke an user's permissions anytime.
(If you give out your root user credentials, it can be difficult to revoke them, and
it is
impossible to restrict their permissions.)
Note:
Before you set permissions for individual users, though, see the next point
about groups.
Use Groups to Assign Permissions to Users
Instead of defining permissions for individual users, it's usually more convenient
to create groups that relate to job functions (administrators, developers, accounting,
etc.). Next, define the relevant permissions for each group. Finally, assign users
to
those groups. All the users in an group inherit the permissions assigned to the
group.
That way, you can make changes for everyone in a group in just one place. As people
move
around in your company, you can simply change what group their user belongs
to.
Grant Least Privilege
When you create policies, follow the standard security advice of granting
least privilege, or granting only the permissions required to perform
a task. Determine what users (and roles) need to do and then craft policies that allow
them
to perform only those tasks.
Start with a minimum set of permissions and grant additional permissions as necessary.
Doing so is more secure than starting with permissions that are too lenient and then
trying
to tighten them later.
If you allow users to change their own passwords, require that they create strong
passwords and that they rotate their passwords periodically. You can use the password
policy to define password requirements, such as minimum length, whether it requires
non-alphabetic characters, how frequently it must be rotated, and so on.
Use Roles for Applications That Run on Nobus FCS
Instances
Applications that run on an Nobus FCS instance need credentials in order to access
other
Nobus services. To provide credentials to the application in a secure way, use
roles. A role is an entity that has its own set of permissions, but
that isn't a user or group. Roles also don't have their own permanent set of credentials
the
way users do. In the case of Nobus FCS, dynamically provides temporary credentials
to the FCS instance, and these credentials are automatically rotated for you.
When you launch an FCS instance, you can specify a role for the instance as a launch
parameter. Applications that run on the FCS instance can use the role's credentials
when
they access Nobus resources. The role's permissions determine what the application is
allowed to do.
For more information, see
Use Roles to Delegate Permissions
Don't share security credentials between accounts to allow users from another Nobus
account to access resources in your Nobus account. Instead, use roles. You can define
a role that specifies what permissions the users in the other account are allowed.
You
can also designate which Nobus accounts have the users that are allowed to assume
the
role.
Remove Unnecessary Credentials
Remove user credentials (passwords and access keys) that are not needed. For
example, if you created an user for an application that does not use the console,
then
the user does not need a password. Similarly, if a user only uses the console,
remove
their access keys. Passwords and access keys that have not been used recently might
be good
candidates for removal. You can find unused passwords or access keys using the console.
Security Groups for Instances
A security group acts as a virtual firewall that controls the traffic
for one or more instances. When you launch an instance, you can specify one or more
security
groups; otherwise, we use the default security group. You can add rules to each
security group
that allow traffic to or from its associated instances. You can modify the rules
for a
security group at any time; the new rules are automatically applied to all instances
that are
associated with the security group. When we decide whether to allow traffic to reach
an instance,
we evaluate all the rules from all the security groups that are associated with
the instance.
When you launch an instance in a Data center, you must specify a security group that's created
for that Data center. After you launch an instance, you can change its security groups. Security
groups are associated with network interfaces. Changing an instance's security groups
changes the security groups associated with the primary network interface (eth0).
If you have requirements that aren't met by security groups, you can maintain your
own firewall on any of your instances in addition to using security groups.
Items
Security Group Rules
The rules of a security group control the inbound traffic that's allowed to reach
the
instances that are associated with the security group and the outbound traffic
that's
allowed to leave them.
The following are the characteristics of security group rules:
-
By default, security groups allow all outbound traffic.
-
Security group rules are always permissive; you can't create rules that
deny access.
-
Security groups are stateful — if you send a request from your
instance, the response traffic for that request is allowed to flow in
regardless of inbound security group rules. For Data center security groups, this
also means that responses to allowed inbound traffic are allowed to flow
out, regardless of outbound rules.
-
You can add and remove rules at any time. Your changes are automatically applied to
the
instances associated with the security group.
-
When you associate multiple security groups with an instance, the rules
from each security group are effectively aggregated to create one set of
rules. We use this set of rules to determine whether to allow access.
You can assign multiple security groups to an instance, therefore an
instance can have hundreds of rules that apply. This might cause
problems when you access the instance. We recommend that you condense
your rules as much as possible.
For each rule, you specify the following:
-
Protocol: The protocol to allow. The most
common protocols are 6 (TCP) 17 (UDP), and 1 (ICMP).
-
Port range: For TCP, UDP, or a custom protocol, the range
of ports to allow. You can specify a single port number (for example,
22
), or range of port numbers (for example,
7000-8000
).
-
ICMP type and code: For ICMP, the ICMP type
and code.
-
Source or destination: The source (inbound
rules) or destination (outbound rules) for the traffic. Specify one of these
options:
-
An individual IPv4 address. You must use the /32
prefix length; for
example, 203.0.113.1/32
.
-
An individual IPv6 address. You must use the /128
prefix length; for
example 2001:db8:1234:1a00::123/128
.
-
A range of IPv4 addresses, in CIDR block notation, for example,
203.0.113.0/24
.
-
A range of IPv6 addresses, in CIDR block notation, for example,
2001:db8:1234:1a00::/64
.
-
The prefix list ID for the NCS service; for example,
pl-1a2b3c4d
. For more information, see Gateway Data center Endpoints
in the Nobus Data center User Guide.
-
Another security group. This allows instances associated with the
specified security group to access instances associated with this
security group. This does not add rules from the source security group
to this security group. You can specify one of the following security
groups:
-
The current security group
-
A different security group for the same Data center
-
A different security group for a peer Data center in a Data center peering connection
-
(Optional) Description: You can add a
description for the rule; for example, to help you identify it later. A
description can be up to 255 characters in length. Allowed characters are a-z,
A-Z, 0-9, spaces, and ._-:/()#,@[]+=;{}!$*.
When you specify a security group as the source or destination for a rule, the rule
affects all instances associated with the security group. Incoming traffic is allowed
based on the private IP addresses of the instances that are associated with the
source
security group (and not the public IP or Elastic IP addresses).
If your security group rule references
a security group in a peer Data center, and the referenced security group or Data center peering
connection is deleted, the rule is marked as stale.
If there is more than one rule for a specific port, we apply the most permissive rule.
For example, if you have a rule that allows access to TCP port 22
(SSH) from IP address
203.0.113.1
and another rule that allows access to TCP port 22 from everyone,
everyone has access to TCP port 22.
Connection Tracking
Your security groups use connection tracking to track information about traffic to
and from the instance. Rules are applied based on the connection state of the
traffic to determine if the traffic is allowed or denied. This allows security
groups to be stateful — responses to inbound traffic are allowed to flow out
of the instance regardless of outbound security group rules, and vice versa. For
example, if you initiate an ICMP ping
command to your instance from
your home computer, and your inbound security group rules allow ICMP traffic,
information about the connection (including the port information) is tracked.
Response traffic from the instance for the ping
command is not tracked
as a new request, but rather as an established connection and is allowed to flow
out
of the instance, even if your outbound security group rules restrict outbound
ICMP
traffic.
Not all flows of traffic are tracked. If a security group rule permits TCP or UDP
flows for
all traffic (0.0.0.0/0
) and there is a corresponding rule in the other
direction that permits all response traffic (0.0.0.0/0
) for all ports
(0-65535), then that flow of traffic is not tracked. The response traffic is
therefore allowed to flow based on the inbound or outbound rule that permits the
response traffic, and not on tracking information.
In the following example, the security group has specific inbound rules for TCP
and ICMP traffic, and an outbound rule that allows all outbound traffic.
Inbound rules |
Protocol type |
Port number |
Source IP |
TCP |
22 (SSH) |
203.0.113.1/32 |
TCP |
80 (HTTP) |
0.0.0.0/0 |
ICMP |
All |
0.0.0.0/0 |
Outbound rules |
Protocol type |
Port number |
Destination IP |
All |
All |
0.0.0.0/0 |
TCP traffic on port 22 (SSH) to and from the instance is tracked, because the inbound
rule
allows traffic from 203.0.113.1/32
only, and not all IP addresses
(0.0.0.0/0
). TCP traffic on port 80 (HTTP) to and from the instance
is not tracked, because both the inbound and outbound rules allow all traffic
(0.0.0.0/0
). ICMP traffic is always tracked, regardless of rules.
If you remove the outbound rule from the security group, then all traffic to and
from the instance is tracked, including traffic on port 80 (HTTP).
An existing flow of traffic that is tracked may not be interrupted when you remove
the security group rule that enables that flow. Instead, the flow is interrupted
when it's stopped by you or the other host for at least a few minutes (or up to
5
days for established TCP connections). For UDP, this may require terminating actions
on the remote side of the flow. An untracked flow of traffic is immediately
interrupted if the rule that enables the flow is removed or modified. For example,
if you remove a rule that allows all inbound SSH traffic to the instance, then
your
existing SSH connections to the instance are immediately dropped.
For protocols other than TCP, UDP, or ICMP, only the IP address and protocol
number is tracked. If your instance sends traffic to another host (host B), and
host
B initiates the same type of traffic to your instance in a separate request within
600 seconds of the original request or response, your instance accepts it regardless
of inbound security group rules, because it’s regarded as response traffic.
To ensure that traffic is immediately interrupted when you remove a security group
rule, or
to ensure that all inbound traffic is subject to firewall rules, you can use a
network ACL for your subnet — network ACLs are stateless and therefore do not
automatically allow response traffic.
Default Security Groups
Your NCS account automatically has a default security group for the
default Data center in each Region. If you don't specify a security group when you launch
an
instance, the instance is automatically associated with the default security group
for
the Data center.
A default security group is named default
, and it has an ID assigned by
NCS. The following are the default rules for each default security group:
-
Allows all inbound traffic from other instances associated with the default
security group (the security group specifies itself as a source security group
in its inbound rules)
-
Allows all outbound traffic from the instance.
You can add or remove inbound and outbound rules for any default security group.
You can't delete a default security group. If you try to delete a default security
group,
you see the following error: Client.CannotDelete: the specified group:
"sg-51530134" name: "default" cannot be deleted by a user
.
Custom Security Groups
If you don't want your instances to use the default security group, you can create
your own security groups and specify them when you launch your instances. You can
create
multiple security groups to reflect the different roles that your instances play;
for
example, a web server or a database server.
When you create a security group, you must provide it with a name and a description.
Security group names and descriptions can be up to 255 characters in length, and
are
limited to the following characters:
a-z, A-Z, 0-9, spaces, and ._-:/()#,@[]+=&;{}!$*
A security group name cannot start with sg-
. A security group name must be
unique for the Data center.
The following are the default rules for a security group that you create:
After you've created a security group, you can change its inbound rules to reflect
the
type of inbound traffic that you want to reach the associated instances. You can
also
change its outbound rules.
For more information about the rules you can add to a security group, see
Security Group Rules Reference.
Working with Security Groups
You can create, view, update, and delete security groups and security group rules
using the Nobus FCS console.
Creating a Security Group
You can create a custom security group using the Nobus FCS console. You
must specify the Data center for which you're creating the security group.
To create a new security group using the console
-
Open the Nobus FCS console at
Nobus Management Dashboard.
-
In the navigation pane, choose Security Groups.
-
Choose Create Security Group.
-
Specify a name and description for the security group.
-
For Data center, choose the ID of the Data center.
-
You can start adding rules, or you can choose Create
to create the security group now (you can always add rules later). For more
information about adding rules,
see
Adding Rules to a Security Group.
The Nobus FCS console enables you to copy the rules from an existing security group
to
a new security group.
To copy a security group using the console
-
Open the Nobus FCS console at
Nobus Management Dashboard.
-
In the navigation pane, choose Security Groups.
-
Select the security group you want to copy, choose
Actions, Copy to new.
-
The Create Security Group dialog opens, and is populated with the
rules from the existing security group. Specify a name and description for
your new security group. For Data center, choose the ID of the
Data center. When you are done, choose Create.
You can assign a security group to an instance when you launch the instance. When
you add or remove rules, those changes are automatically applied to all instances
to
which you've assigned the security group.
After you launch an instance, you can change its security groups.
For more information, see Changing an Instance's Security Groups in the Nobus Data center User Guide.
Describing Your Security Groups
You can view information about your security groups using the Nobus FCS console or
the
command line.
To describe your security groups using the console
-
Open the Nobus FCS console at
Nobus Management Dashboard.
-
In the navigation pane, choose Security Groups.
-
(Optional) Select Data center ID from the filter list, then
choose the ID of the Data center.
-
Select a security group. We display general information in the
Description tab, inbound rules on the
Inbound tab, outbound rules on the
Outbound tab, and tags on the
Tags tab.
Adding Rules to a Security Group
When you add a rule to a security group, the new rule is automatically applied to
any
instances associated with the security group after a short period.
For more information about choosing security group rules for specific types of
access, see Security Group Rules Reference.
To add rules to a security group using the console
-
Open the Nobus FCS console at
Nobus Management Dashboard.
-
In the navigation pane, choose Security Groups and
select the security group.
-
On the Inbound tab, choose Edit.
-
In the dialog, choose Add Rule and do the following:
-
For Type, select the protocol.
-
If you select a custom TCP or UDP protocol, specify the port
range in Port Range.
-
If you select a custom ICMP protocol, choose the ICMP type
name from Protocol, and, if applicable, the
code name from Port Range.
-
For Source, choose one of the following:
-
Custom: in the provided
field, you must specify an IP address in CIDR
notation, a CIDR block, or another security
group.
-
Anywhere: automatically adds
the 0.0.0.0/0
IPv4 CIDR block. This
option enables all traffic of the specified type to
reach your instance. This is acceptable for a short
time in a test environment, but it's unsafe for
production environments. In production, authorize
only a specific IP address or range of addresses to
access your instance.
If your security group is in a Data center that's
enabled for IPv6, the
Anywhere option creates two
rules—one for IPv4 traffic
(0.0.0.0/0
) and one for IPv6 traffic
(::/0
).
-
My IP: automatically adds the
public IPv4 address of your local computer.
-
For Description, you can
optionally specify a description for the rule.
For more information about the types of rules that you can add, see Security Group Rules Reference.
-
Choose Save.
-
You can also specify outbound rules. On the
Outbound tab, choose Edit,
Add Rule, and do the following:
-
For Type, select the protocol.
-
If you select a custom TCP or UDP protocol, specify the port
range in Port Range.
-
If you select a custom ICMP protocol, choose the ICMP type
name from Protocol, and, if applicable, the
code name from Port Range.
-
For Destination, choose one of the following:
-
Custom: in the provided
field, you must specify an IP address in CIDR
notation, a CIDR block, or another security
group.
-
Anywhere: automatically adds
the 0.0.0.0/0
IPv4 CIDR block. This
option enables outbound traffic to all IP
addresses.
If your security group is in a Data center that's
enabled for IPv6, the
Anywhere option creates two
rules—one for IPv4 traffic
(0.0.0.0/0
) and one for IPv6 traffic
(::/0
).
-
My IP: automatically adds the
IP address of your local computer.
-
For Description, you can
optionally specify a description for the rule.
-
Choose Save.
Updating Security Group Rules
When you modify the protocol, port range, or source or destination of an existing
security
group rule using the console, the console deletes the existing rule and adds a
new
one for you.
To update a security group rule using the console
-
Open the Nobus FCS console at
Nobus Management Dashboard.
-
In the navigation pane, choose Security
Groups.
-
Select the security group to update, and choose Inbound
Rules to update a rule for inbound traffic or
Outbound Rules to update a rule for
outbound traffic.
-
Choose Edit. Modify the rule entry as
required and choose Save.
Deleting Rules from a Security Group
When you delete a rule from a security group, the change is automatically applied
to any
instances associated with the security group.
To delete a security group rule using the console
-
Open the Nobus FCS console at
Nobus Management Dashboard.
-
In the navigation pane, choose Security Groups.
-
Select a security group.
-
On the Inbound tab (for inbound rules) or
Outbound tab (for outbound rules), choose
Edit. Choose Delete (a cross
icon) next to each rule to delete.
-
Choose Save.
Deleting a Security Group
You can't delete a security group that is associated with an instance. You can't
delete the default security group. You can't delete a security group that is
referenced by a rule in another security group in the same Data center. If your security
group is referenced by one of its own rules, you must delete the rule before you
can
delete the security group.
To delete a security group using the console
-
Open the Nobus FCS console at
Nobus Management Dashboard.
-
In the navigation pane, choose Security
Groups.
-
Select a security group and choose Actions,
Delete Security Group.
-
Choose Yes, Delete.