Give people the least access they need and audit what they do
Most security incidents inside a team are not attacks. They are an over-powerful account, a forgotten member or a shared token used for the wrong thing. The defence is the same every time: give each person the smallest set of permissions that lets them work, limit what they can see, and look at what actually happened now and then.
This article shows the tools SrvYard gives you for that: roles, teams, the member list, the API scopes that follow the same permissions, and the activity feed that records who did what.
Before you begin
- Owner or admin rights. Changing roles and teams needs the
members:manage,roles:manageandteams:*permissions. Members and viewers can read the lists but not change them. See Roles and permissions. - A rough map of your team. Who deploys, who manages servers, who only needs to look. Write it down before you change anything.
- The principle. Start with the lowest role that works, and add access when someone asks, not the other way round.
A role decides what a person may do; a team decides what they may see. A member needs both: the permission to deploy and a team that includes the site.
1. Choose the right role
Open Organization settings > Roles.
- New role. Creates a custom role from the permission list.
- The built-in roles. Each row shows how many of the 102 permissions the role holds. Owner holds all of them. Admin holds nearly all, except managing or assigning Owner roles. Manager manages servers and the team but not billing or organisation settings. Developer has full access to servers and sites but cannot create new servers. Viewer can see all servers, sites and sensitive data without making changes.
- A custom role. Marked Custom. The example, Release manager, can see everything and run deployments but not change servers: five permissions of 102.
Practical choices:
| The person | Role |
|---|---|
| Founder, the one who pays | Owner, and a second owner as a spare. |
| Someone who runs the infrastructure | Admin or Manager. |
| A developer who deploys | Developer. |
| A client, an auditor, a manager who only reads | Viewer. |
| Someone with a narrow job, such as deploy only | A custom role. |
Everyone who is not an owner can be restricted further. Keep the number of owners and admins small: they can add keys and commands to servers, which makes them root-equivalent for the servers they reach.
Create a custom role that looks like the job (for example "Release manager") instead of loosening a built-in role. A built-in role stays predictable, and a custom role documents why someone has what they have.
Some permissions deserve extra care because they reach secrets or remote code: sites:manage-environment (the .env file), servers:view-credentials (sudo and database administrator passwords), sites:manage-commands (arbitrary commands), tokens:manage (API tokens) and members:impersonate. Leave them out of roles that do not need them.
2. Review the members
Open Organization settings > Members.
- Invite member. Sends an invitation with a role. Pick the role here, not later; an invitation carries the role it was sent with.
- Role. Change a member's role from the drop-down on their row, with Manage for more options. The owner row has no drop-down.
- Revoke. Cancels a pending invitation. They expire on their own, here on 29 October. Revoke any invitation sent to a wrong address.
Check the list at the end of every project and when someone leaves the company: remove the member, then check their SSH keys on servers and the API tokens they created (a member's tokens stop working when the member is removed, but keys added to servers stay until you remove them). The Auth method column tells you whether the member signs in with a password or a social account, and an owner can require two-factor for all of them. See Turn on two-factor authentication and manage your sessions.
3. Limit what people can see
Open Organization settings > Teams.
- New team. A team is a group of members given access to specific servers and sites. Each row shows how many members, servers and sites it covers.
Owners and admins always see everything. Other members see what their teams share, plus what they created themselves. A contractor who works on one storefront belongs only to the team of that storefront and sees nothing else. See Limit members to certain servers and sites.
The same boundaries apply to the API: a token acts as its owner, so a member who is limited to some servers can only list those, and everything else answers 404.
4. Look at who did what
SrvYard records changes as they happen. The most useful place is the Activity tab of a server or a site.
- Type. Filter to deployments, firewall changes, SSH keys, daemons and so on.
- By. The member who did it, or SrvYard for what the system did itself.
- When. Newest first. The feed keeps the last 14 days.
Sensitive changes are also written to an audit record with the member, the time and the address, and a staff action done on your behalf carries the staff member's name. Changes made through an API token are recorded with the actor token:<name>, with no request body. The same feed is available to scripts through the API (scope activity:view), so you can copy it somewhere that keeps it longer than 14 days. See The activity log and audit trail.
5. Use the API scopes to keep automation small
Every API token carries scopes taken from the same permission list as roles, and can never exceed the role of the member who created it. That gives you a second lever: even an owner can create a token that may only read servers, or only deploy one kind of change. Create tokens with Read-only as the starting point and add single write permissions. If a role is demoted, the tokens of that member lose the extra power on their next call. See Create an API token and pick scopes.
For people, the equivalent habit is to promote on demand: give a developer the Manager role for the day of a migration, and move them back to Developer afterwards. The change is recorded like any other.
6. A quarterly review
A fifteen-minute routine catches most drift:
- Members: is everyone still on the team? Is every role the lowest that works?
- Owners and admins: can the number be smaller? Do they all have two-factor?
- Teams: does each person see only what they need?
- Tokens: open Settings > API tokens for your own tokens, and ask others to review theirs. See Rotate tokens and review the sign-in log.
- SSH keys: remove keys of people and machines that no longer need access.
- Webhooks and channels: are all the addresses still yours?
Troubleshooting
- A member cannot see a site that they need. The role may be right but the team is missing. Add the site to a team they belong to.
- A member can deploy but not change the
.env. That is a separate permission,sites:manage-environment. Give it to a custom role if the job needs it. - I cannot change the owner's role. The owner row shows the role as plain text, without a drop-down. Ask support if ownership has to move.
- A removed member's name still shows in the activity feed. Past entries keep the name of whoever did them.
- I need history older than 14 days. The feed does not keep it. Copy it regularly through the API.
- Someone did something and nobody knows who. Check the By column, the site's activity and the webhook deliveries of your own systems. If a token was involved, the entry names it.
Related
- Roles and permissions: every permission and the built-in roles.
- Limit members to certain servers and sites: teams in detail.
- The activity log and audit trail: the 14-day feed and where audit entries fit.
- What SrvYard stores and how credentials are encrypted: how the secrets behind these permissions are protected.