AWS Permissions
General Ideas#
- Principle of least privilege applies to all users/groups. In other words, we only grant permissions access at a level necessary for users to undertake their work.
- Groups – and as often possible not individuals – with common access needs should be assigned access to accounts with appropriate permissions. See below for exceptions.
- No adding teams by default. We do not assign an entire Hackney team the same access permissions as one another. Instead, those within a team that need access to AWS will get it. Seniority does not mean superior access.
- Requesting permissions is done by email to cloudsupport[at]hackney[dot]gov[dot]uk. We ask that requesters provide the following information:
- the name of the team/project
- the account(s) they need to access
- a similar user
- their full name and Hackney email
Google / SAML groups#
We federate user access from our Google directory. This means users will automatically be able to access an application by logging in with their Hackney Google Account (SSO). Our aim is to organise most access to AWS accounts and AppStream applications via groups of users with similar access needs. This is done via groups created in our Google directory that begin with the prefix saml-.
Types of Users Needing Access#
The types of users currently accessing Hackney’s AWS environment can be roughly divided into three categories:
Those building (in) the platform*;
Those working with resources that have been built (by others) in the platform;
Those needing access to a certain service in the platform – e.g. AppStream – in order to do their work.
NB Even for those building (in) the platform, the majority of resources should be created using Infrastructure as Code and CI/CD pipelines, which use automated deployment roles rather than individuals’ access permissions. As a result, although it can be argued that those building (in) the platform do require elevated permissions from time to time, their access permission level should still be moderate or limited.
Creating groups#
Currently, we must request that a member of the Service Support team create a group. Soon there is likely to be a new process for requesting groups that is more auditable, provided by Halo. Please request that any new groups’ names follow our guidelines below.
Naming conventions for Google (SAML) groups#
Group Email Identifier#
<authentication mechanism> | - | <cloud platform> | - | <appstream> | - | <application/project/service/team name> | - | <special features> | @hackney.gov.uk |
e.g. saml | e.g. aws | Where necessary | e.g. hrapplication1 , financeapplication1 | Where necessary see below |
Special Features#
Designation for groups with special access privileges or other features worthy of note. General access groups carry no designation.
These suffixes are compoundable with hyphens, e.g., admin-staging.
| Value | Description |
admin | The group carries out administrative tasks requiring a higher privilege level and access to other associated software not normally available |
readonly | The group does not have ordinary access to the application, and cannot change or manipulate data |
staging | A group configured only for use in a staging environment, to test the application and configurations. |
developer | A group specifically tailored to Hackney developers and their work. |
Group Description#
This should always be completed by an Owner/Manager of the google group upon creation. The description should clearly describe:
- what service users will gain access to by being added to the group;
- any special arrangements in place for adding users to the group;
- identify services the application is hosted on and links to relevant documentation.
For example:
Add general users for financeapplication1 to this group. The application is delivered via AWS AppStream and further documentation can be found here: link.
Group Permissions#
As these groups are used to control access to applications, it’s important that the groups are properly configured to prevent users being added/removed without authorisation.
| Option | Value |
| Access Type | Restricted |
| Contact Owners | Group Members |
| View Members | Group Managers |
| View Conversations | Group Members |
| Publish Posts | Group Managers |
| Add, invite, approve new members | Group Managers |
| Who can join this group | Only invited users |
| Allow members outside your organisation | False |
Group Membership#
The default Group Owner should be set to a G Suite (Service Account) unless there’s a technical reason to use an alternative service account. The Group Owner must not be set to a specific user.
Our aim is to ensure that the management of these groups will quickly pass over to the team leads – preferably Hackney staff – who operationally manage access to the account/application in question. The Group Managers will add new Group Members as needed.
Once a group has been created, Managers can add Members to the group as described in this Google documentation, section Add people to your group directly.
Individual Access to an account#
Although it is preferable that groups are given access rather than individuals, there are some cases in which giving an individual access may be more secure than giving a group access. Good reasons for granting an individual access to an account:
- If that individual’s access is temporary;
- If, by granting a group access instead of an individual, you would be granting access to other individuals who should not have access to that account.
Syncing a New Group with AWS#
Follow the guide for adding a new group to Parameter Store.
Adding members / groups via SCIM#
Although it is preferable to simply add users to their respective groups and wait for the SSO Sync to run, it is possible to quickly add groups or add users to existing groups via Postman and SCIM. Please ask those existing members of the team who have this set up to help.
Permission Sets#
We are currently using a variety of custom and AWS permission sets in order to grant access to different Google groups across Hackney’s AWS environment. The way in which we use these permission sets is likely to change soon. Permission sets consist of both custom/inline and managed policies. Read more on permission sets here.
Custom Permission Sets#
We use a range of custom permission sets based around the different types of users listed above.
AWS Permission Sets#
| Permission | Usage model | Notes |
|---|---|---|
| AWSReadOnlyAccess | This policy grants permissions to view resources and basic metadata across all AWS services | This permission set can be applied widely with minimal risk. |
| AWSPowerUserAccess | Provides full access to AWS services and resources, but does not allow management of Users and groups | This permission set is far too powerful for most users. It should be granted sparingly and preferably in lower environments. |
| AWSAdministratorAccess | Provides full access to AWS services and resources | This permission set should be granted extremely sparingly in Production environments; preferably those who need it should only be temporarily elevated to this permission set before being demoted to a more safe access level. |