SPEKTRA Edge offers the Identity and Access Management (IAM) framework
for the user management, which is based on the Role-Based Access Control (RBAC)
mechanism. In other words, you apply the certain role or roles to the users or
groups, which is called the role binding, to give the certain permissions to
the particular individual or group of individuals.
It also has a concept of scope of role binding, which is that the permissions
for the particular role only applicable in the certain scope. This means that the
role binding happened at the project is only effective under that project, or
sub-projects if those available, but not others, like parent projects.
This means that you can create a really powerful and effective user management
mechanism with the well-organized projects or organization structure.
Put together, every grant of access on SPEKTRA Edge answers three questions:
who, what, and where.
flowchart LR
WHO["<b>Who</b><br/>a user, a group,<br/>or a service account"] --> RB
WHAT["<b>What</b><br/>a role, such as<br/>Owner or Viewer"] --> RB
WHERE["<b>Where</b><br/>a scope: an organization,<br/>a project, or a service"] --> RB
RB["<b>Role binding</b>"] --> OUT(["This principal has this role's<br/>permissions — but only<br/>inside this scope"])
Scopes inherit downwards only. A role granted on an organization applies to
the projects beneath it; a role granted on a project does not grant anything on
its parent or on a sibling project.
Granting access means choosing a role, so it is worth knowing what the roles
mean before you grant anything. These are the pre-existing user roles offered
by SPEKTRA Edge.
Role name
Resource name
Permissions
Owner
scope-admin
All operations on core and third party services
Admin operator
admin-operator
All operations on core services
Device operator
devices-operator
All operations on device and applications services
Application operator
apps-operator
All operations on applications services
Viewer
viewer
Read-only operations on core services
The owner role has full access to the services offered by SPEKTRA Edge
under particular scope.
The admin operator role is similar to the owner role but does not have
access to the third-party services, for example the watchdog service offered
by Service Experience Insight. This is a good role for someone who
manages the entire service, e.g., user management.
The devices and application operator roles are both for the application
management. The devices operator role is good for someone who manages both
devices and applications but the application operator is for the application
management only.
The viewer role has read access to core services but no write
access. This is a good role for someone who only monitors or observes
core services.
Grant access to users
With a role in mind, you can grant someone access.
Click the Grant access button in the Manage resources and access of
this project blue bar on the Project overview page, which will ask you for:
the E-mail address of the person you want to give access to the project
Selecting the role for the user in the Grant access to project dialog on the Project overview page.
Organize users by groups
You can create a group to manage multiple users in one-shot.
One good example of the group usage is to grant access to multiple users
in a single operation, as explained in the following section.
To create a group, click the Create group button on the Project overview
page and fill in the required information, such as the name and the region, as
well as the E-mail addresses of the members managed in the group.
Creating Your team group under Your project.
Grant access to groups
You can grant access to the group, which is a great way to grant access to
multiple users in the efficient fashion.
To do that, use the group E-mail address to grant access instead of the
individual person’s E-mail. The group E-mail address is constructed by
SPEKTRA Edge with the following convention.
[Group name]@[Project name].groups.iam.edgelq.com
You can also get the group E-mail address on the groups overview page
under your project.
The group E-mail address on the groups overview page.
Grant access by clicking the Grant access button on the
Project overview page. Give the group E-mail address,
your-team@your-project.groups.iam.edgelq.com for this example, and the role
you want to grant access to the group.
Granting access to the group with the group’s E-mail address.
You can check the roles for the group members by going to the Access page under
the IAM section. You can see all the group members have the same role of
the group’s role.
All the group members have the same role of the group’s one.
Group role binding
It takes a while, a minute or two, before the role binding completes on
the group members because it is done by the SPEKTRA Edge controllers behind the
scenes in the eventual consistency fashion.
In this section
Organizations and projects — how projects and organizations are structured, what
descendants inherit, and the choices that are hard to undo.
User authentication — sign up, sign in, and set up
multi-factor authentication.
Service accounts — identities for automation and
devices, and the keys they authenticate with.
Manage resource limits — the resource quotas that apply to a
project, and how to request and approve changes to them.
Next steps
Congratulations on understanding how to manage users on SPEKTRA Edge.
With the power of the scope based role binding, you can conduct the
user management with achieving the high security standard.
The role binding is one side of the user management coin. The other
side of the user management is the user sign-up and sign-in.
Let’s dive into user authentication to understand the
full picture of the user management on SPEKTRA Edge.
1 - Organizations and projects
How projects and organizations are structured, and the choices that are hard to undo.
Before you create anything on SPEKTRA Edge you make two structural decisions:
how to divide your fleet into projects, and how those projects sit under
organizations. Both are cheap to get right at the start and awkward to change
later, because a resource’s name — and therefore its identity — includes the
project it belongs to.
This page explains the model and flags the choices to make deliberately.
Projects
A project is the unit of ownership and isolation. It holds devices,
applications, secrets, metrics, alerting policies, and the role bindings that
say who may touch them. Almost every resource on the platform lives inside one.
Two projects share nothing by default. A device in one is invisible to the
other, a secret cannot be read across the boundary, and access granted in one
grants nothing in the other. That makes the project the natural boundary for
anything you want kept genuinely separate — customers, environments,
business units.
The trade-off is that separation is not free. Anything you want to see across
projects — a fleet-wide view, one alerting policy, a single dashboard — has to
be assembled per project, because queries do not span them. Split for
isolation you actually need, not for tidiness.
Organizations
An organization groups projects, and organizations can nest inside other
organizations to mirror how your business is actually structured.
An organization carries three things its descendants inherit:
Access. A role binding at organization level applies to every project
beneath it. This is how you grant a platform team access once instead of
project by project.
Region policy. Which regions descendants may use, and which is the
default.
Which services descendants may enable, and the default business tier
they get.
Inheritance flows downward only. A role granted on a project confers
nothing on its parent organization or on a sibling project. When someone can
see more than you expected, look upward from the resource, not sideways.
Every project records its full ancestry, so the effective access on a resource
is the union of every binding from the root organization down to the project
holding it.
Regions
A project’s region policy does two jobs:
Enabled regions — the complete set of regions in which resources may be
created. Creating a resource outside them is refused, not silently
redirected.
Default region — the one that handles resources not tied to a region of
their own.
Region is part of a resource’s identity, not a routing hint, so the
choice has consequences beyond latency:
Limits are per region. A project enabled for two regions has two separate
allowances for each resource type, not one shared pool. See
Resource limits.
Secrets do not cross regions. A secret in one region is not visible to a
device in another; a multi-region fleet needs the secret created in each
region it occupies. See Secrets.
Queries are per region unless you deliberately widen them. The -
wildcard reads across every region a project uses.
Enable the regions you need and no more. Adding one later is straightforward;
having resources scattered across regions nobody meant to use is not.
Choices that are hard to change
Most of what you set when creating a project can be edited afterwards. These
cannot, or not without disruption.
Choice
Why it is hard to undo
Project ID
Permanent. It appears in the name of every resource in the project, so changing it would mean recreating all of them. The display name is separate and freely editable.
Parent organization
Determines inherited access and policy. Moving a project is not a routine operation.
Enabled regions
Adding is fine. Removing a region means migrating or deleting everything in it first.
Business tier
Drives the default limits your project receives. Changing it later means renegotiating limits, not flipping a switch.
Service project
A project created for developing your own platform service behaves differently from a normal one, and this is decided at creation.
Pick the project ID deliberately. Something short, stable, and meaningful to a
human reading a resource name two years from now — acme-retail-prod, not
project-2 or a name containing a team that may be reorganized.
Business tier
The business tier — XSMALL, SMALL, MEDIUM, or LARGE — describes the
expected size of the project and determines the default limits it is granted.
Organizations set a default that child projects inherit unless they specify
their own, and individual services can be given a different tier from the
project’s overall one.
Start at the tier that matches your real intent. Under-sizing means requesting
limit increases almost immediately; over-sizing reserves capacity you are not
using.
Optional services
Some capabilities are not enabled by default and are switched on per project —
Service Experience Insights, ZTNA, and the AI service among them.
Two gates apply, in order. The parent organization decides which services its
descendants are allowed to use, and the project then decides which of those
it enables. If a service appears unavailable when creating a project, the
organization is usually the reason, not the project.
Enabling a service adds capability but also adds surface area — sidebar
sections, resources, and permissions. Enable what you intend to use.
Structuring your projects
There is no universally right shape, but the trade is consistent: more projects
buys isolation and costs you cross-cutting visibility.
Common patterns:
By environment — separate production from staging so that access,
limits, and an accidental bulk delete cannot cross the boundary. The most
commonly worthwhile split.
By customer or site group — where you genuinely need one project unable
to see another. Note that limits are shared with child projects, so a
hierarchy of customer projects needs the parent’s limits sized for all of
them.
By business unit, under organizations that mirror the reporting
structure — so that access follows existing lines rather than being
maintained by hand.
What usually does not justify a separate project is a group of devices you
merely want to manage together. Labels do that job within one project,
while keeping one view of the fleet and one set of alerting policies.
Next steps
Accounts & access — granting people and services access to
what you have created.
Sign up, sign in, and set up multi-factor authentication.
Let’s learn how to sign-up and sign-in on SPEKTRA Edge.
The previous topic, the user and group management, discussed how to
manage users with groups and role bindings. In fact, that’s one side of the
coin of the user management. The other side, the user sign-up and sign-in,
is the topic in this page.
SPEKTRA Edge user authentication is the multi-factor authentication
(MFA) with Google Sign-in support. Let’s learn how it
works step-by-step both for the Google accounts and for the E-mail/password
based authentication.
What you need
For the user authentication on SPEKTRA Edge, you need the following.
Let’s learn the sign-up process on SPEKTRA Edge first.
Select Google accounts or Email and password tab below to learn the process
for each case.
Select the Sign Up tab and click Sign up with Google option.
Clicking Sign up with Google to sign-up with Google accounts.
You will be asked to select the MFA app. Select your preferred MFA app and
move on to the MFA setup step next.
Selecting the Google Authenticator to move on to multi-factor authentication setup step.
Scan the QR code by the MFA app on your phone and fill in the six-digit pass code
generated by the app.
Scan the QR code with the MFA app and fill in the six-digit pass code generated by the app.
That’s it. You’ve successfully signed up for SPEKTRA Edge and will be redirected to
the SPEKTRA Edge dashboard.
Select the Sign Up tab and click SIGN UP after filling in the E-mail,
password, and the full name.
Clicking SIGN UP after filling in the E-mail, password, and the full name.
You will be asked to select the MFA app. Select your preferred app and move on
to the MFA setup step next.
Selecting the Google Authenticator to move on to multi-factor authentication setup step.
Scan the QR code by the MFA app on your phone and fill in the six-digit pass code
generated by the app.
Scan the QR code with the MFA app and fill in the six-digit pass code generated by the app.
You’ve successfully set up MFA for your account. The last thing is to
verify your E-mail address. Click continue and move on to the E-mail verification
step.
Click Continue to move on to the E-mail verification step.
Open your E-mail application and search for the verification E-mail sent by SPEKTRA
Edge in your inbox. Click the Verify email address box in the verification
E-mail to complete the sign-up process.
Clicking the Verify email address to complete the sign-up process.
You will be directed to the SPEKTRA Edge dashboard and successfully complete
the SPEKTRA Edge sign-up process.
Sign-in
Select the account type below to go through the sign-in process on SPEKTRA Edge.
Click the Sign In with Google button to sign-in to SPEKTRA Edge.
Clicking Sign in with Google to sign-in with Google.
You will be asked to fill in the MFA pass code. Open your MFA app and paste
the code generated by the app, then click the right arrow
button to complete the sign-in process.
Fill in the MFA code to complete the sign-in process.
You will be re-directed to the SPEKTRA Edge dashboard.
Fill in your E-mail address and the password you gave during the sign-up process
and click LOG IN button to proceed.
Sign-in with your E-mail address and password.
You will be asked to fill in the MFA pass code. Open your MFA app and paste
the code generated by the app, then click the right arrow button to complete
the sign-in process.
Fill in the MFA code to complete the sign-in process.
You will be re-directed to the SPEKTRA Edge dashboard.
Remember this browser option
You can check the Remember this browser option when you sign-in to the
SPEKTRA Edge to by-pass the MFA process for the next time on this browser.
Please refrain from this option on public browsers, e.g. browsers offered
at hotels, which will be shared by multiple people and leads to the security
breach.
Next steps
Congratulations on completing the user authentication process on
SPEKTRA Edge.
Let’s go to the resource limits page to learn how to manage
resources on SPEKTRA Edge, next.
Onwards.
3 - Service accounts
Identities for automation and devices, and the keys they authenticate with.
Not every caller is a person. Scripts, CI pipelines, monitoring integrations,
and the devices themselves all need to authenticate, and none of them should do
so as a human being. A service account is the identity they use instead.
Using one is not merely tidier. A human account carries whatever access that
person has accumulated, disappears when they leave the company, and gives you
no way to tell which automation did what. A service account has exactly the
access you granted it, outlives any individual, and shows up in the audit trail
under its own name.
What a service account is
A service account belongs to a project and lives in a region:
It is a principal like any other. It appears in role bindings, in audit logs,
and in the dashboard’s access lists alongside users and groups.
Create one per job
Create a separate service account for each distinct job rather than one shared
account for “automation”. They cost nothing, and the benefits compound:
Each gets only the access its job needs, so a compromised credential has a
bounded blast radius.
You can revoke one without breaking the others.
The audit trail tells you which job did something, not just that
something did.
Name them after the job — ci-deploy, metrics-export, fleet-inventory —
not after the person or team that created them.
cuttle iam create service-account fleet-inventory \
--project $PROJECT --region $REGION
Keys
A service account is an identity; a key is how a caller proves it holds
that identity. You choose the type when you create the key.
Type
What you get
Suits
API key
A single bearer token.
Shell scripts, CI jobs, REST calls.
RSA keypair
A private key returned to you once.
gRPC clients and long-running services.
cuttle iam create service-account-key ci \
--parent projects/$PROJECT/regions/$REGION/serviceAccounts/fleet-inventory \
--algorithm API_KEY \
-o json
The key is shown once
The platform does not retain the secret half of a key. The create response is
the only copy you will ever receive. If it is lost, delete the key and create
a replacement.
Because of that, prefer writing the credentials straight to a file over copying
them out of terminal output, where they linger in your scrollback and shell
history:
cuttle iam create service-account-key ci \
--parent projects/$PROJECT/regions/$REGION/serviceAccounts/fleet-inventory \
--algorithm RSA_2048 \
-c ./ci-credentials.json
A key can also be given a validity window. Setting an expiry is the simplest
way to ensure a credential issued for a short-lived job cannot quietly remain
valid for years.
Rotating a key
An account can hold more than one key at a time, so rotation needs no
downtime:
Create a second key.
Deploy the new value wherever the old one is used.
Confirm traffic is succeeding on the new key.
Delete the old key.
Deleting takes effect immediately and cannot be undone, so do not skip step 3.
Where to keep keys
The failure to design against is a credential sitting somewhere you did not
intend, still valid months later.
Never commit key material to a repository — application or infrastructure.
Inject it at runtime from your CI system’s secret store or your platform’s
secret manager.
Prefer a mounted file over an environment variable, which leaks into logs,
crash dumps, and child processes.
Give keys an expiry so that forgotten ones lapse on their own.
Granting access
A new service account can authenticate and do nothing at all. It needs a role
binding, exactly like a user, and the member string must carry the
serviceAccount: prefix:
Grant the narrowest role that works. A job that reads a device inventory needs
read access and nothing more; if it later needs to write, widen it then.
As with users, role bindings take a minute or two to become effective, so a
PERMISSION_DENIED immediately after granting access usually means “not yet”
— see Accounts & access.
Restricting where a key works
A role binding can carry a condition that constrains it further. The most
useful for automation is an IP condition — a list of CIDR ranges the caller
must come from. Applied to a key held by a CI runner with stable egress
addresses, it means a leaked credential is not usable from anywhere else.
Device service accounts
Devices authenticate the same way. When a device is provisioned it receives its
own service account, and the credentials on its disk are a service account key
— which is why a provisioning policy specifies the role each new device’s
account should be granted.
You do not normally manage these by hand, but knowing they exist explains two
things you will see: devices appearing as principals in your audit logs, and a
device’s access being governed by exactly the same role bindings as everything
else.
When a device is decommissioned, its service account should go with it.
Removing the device through the dashboard or the API handles this; manually
deleting a device record without cleaning up its identity leaves a credential
that can still authenticate.
Three numbers describe every limit, and telling them apart saves a lot of
confusion later.
Value
Meaning
Usage
How many of that resource exist right now.
Configured limit
The ceiling your plan currently allows.
Active limit
The ceiling actually being enforced.
Normally the configured and active limits are equal, and the dashboard shows
one number. They diverge in two situations: briefly, while a change you just
made propagates; and, more importantly, when a limit is lowered at the moment
usage is rising. In that case the active limit holds the older, higher value
rather than retroactively putting you over quota. A lasting difference between
the two is a signal worth investigating, not a display quirk.
A limit is not something you set. It is derived from the plan assigned to
your project, which is why the dashboard offers you a request rather than
an edit field: the request adjusts the underlying plan assignment, and the
limit follows. The same is true through the API — the limit resource is
read-only, and writing to it is not possible.
Limits are per region
This is the part that surprises people. A limit applies to a resource type
in a region, so a project spanning two regions has two separate allowances
for the same resource type, not one shared pool.
A limit of 25 pods in a project enabled for us-west2 and eu1 means 25 pods
in each — 50 in total. Conversely, having room in one region does not help a
device trying to start a pod in the other.
Resources that are not themselves regional draw against every region the
project occupies, so enabling an additional region affects them too.
Limits are shared with child projects
The limit applies not only to the current project but to any child projects
beneath it. If the current project’s pod limit is 25, the total across the
current project and all its children is 25 — children draw from the same
allowance, not their own.
Plan for this before building a deep project hierarchy: a parent limit sized
for one team’s use will not accommodate ten child projects.
When you hit a limit
An API call that would exceed a limit fails with RESOURCE_EXHAUSTED
(HTTP 429). Retrying will not help — the request was refused because the
resource does not fit, not because you called too often. Raise the limit or
free something up.
For automation, check headroom before a bulk create instead of discovering the
ceiling part-way through; a half-finished bulk operation is more work to
reconcile than one that never began.
Retention policies
Limits cap how many things exist. Retention policies are the related
control over how long time-series and log data is kept, and are worth reviewing
alongside limits — they determine both how far back you can investigate an
incident and how much stored data your project accumulates.
Request resource limit changes
First step to manage the resource limits is to request the limit change.
Let’s go to the Limits overview page by clicking the Limits option from
the side bar menu.
Clicking the Limits icon on the dashboard side bar menu.
Click the Change limits button to open the Request resource limit change
dialog.
Clicking the Change limits button on the Limits overview page.
Let’s request the Pod resource increase from 25 pods to 50.
Request the Pod resource increase.
That’s it for the resource limit request.
Requesting the right amount
Remember that the figure you request is per region, and is shared with any
child projects. Size it for the whole subtree in one region, not for this
project alone.
Approve resource limit changes
After the resource limit requests, the remaining task is to approve the request to make
it effective.
Click the Change limits requests tab to show the list of change limit requests.
Click the Change limits requests tab to show the list of change limit requests.
Approve the request by selecting the Approve option of the Actions column.
Approving the pod resource limit request by selecting the Approve option of the Actions menu.
That’s it!
Next steps
That is the end of the Learn path: you can set up devices, run applications on
them, watch them, and control who else can.
If you operate Service Experience Insights, continue with Insights.
If you want to drive all of this from your own code rather than the dashboard,
Integrate is the place to go.
