HARBOR CLOUD / 01 / PRACTICE GUIDE
Cloud identity, IAM and RBAC
Harbor Desk now runs in the cloud. Separate human, pipeline and workload identities, and demonstrate least privilege without confusing sign-in with resource authority.
Download guide and workpapersOriginal AI-assisted SecNet educational content; examples are fictional. Not a source organization publication or endorsement. Sources checked: 2026-10-21.
CODE REVIEW DESK
See the decision through the test.
Code here is a local policy model with no target connection. Passing model cases are not security approval or device tests.
Sign-in or authority? / Weak code
Inspect an incomplete decision based on record existence or another positive signal. Consider denial cases alongside permitted use.
s=>s.signedInsignedIn is only an identity signal. Require the same tenant and read-ticket scope separately; wrong action and tenant are denied. This model is not a complete cloud IAM engine.
Choices and outputs last only on this open page; they do not update account progress, career status, points or certificates.
01 / EXPLANATION
Responsibility and identity boundaries
Using a managed service does not delegate application data authorization to the provider. Assign separate responsibility for resources, identity issuance, policy and evidence. Use strong authentication and controlled emergency access for people, and short-lived scoped identities for workloads. Sharing one administrator key across development, deployment and runtime expands incident impact. Real provider roles are not identical to the abstract permissions used in this exercise.
02 / EXPLANATION
Federation acceptance conditions
A signed token is not necessarily the intended workload. Verify expected issuer, audience, subject and lifetime, and bind trust to a specific repository, branch or environment. Include a fork job trying to gain production deployment identity as a negative case. signatureValid represents an evidence assumption here; the browser does not verify signatures or contact an identity provider. Test new federation rules narrowly using observed allowed and denied requests.
03 / EXPLANATION
Indirect authority through RBAC
A namespaced role is not inherently low risk. Examine how bind, escalate, impersonate and secret-reading privileges can yield other authority. Pod creation may also affect workload identity and mountable secrets. Select only required objects and actions for the Harbor reader, and map the full role/binding chain in production. Negative tests should include wrong tenant and wrong action. Do not infer effective authority from a role named reader.
04 / EXPLANATION
Worked example: the north reader
The north reader may read its own tenant’s ticket; a south record and delete-backup action are denied. Record all three outcomes using the same test identity. Next, change only audience or subject in the federation scenario to isolate the trust condition. Actual evidence needs identity origin, role/binding revision, resource scope, denial response and an owner for approved exceptions. Passing the model does not establish that these records exist. An auditor should connect policy text with effective authority and observed outcomes.
Build the evidence yourself.
Blank workpapers are not completed tests. Fill them in your authorized environment without secrets or real personal data.
Full guide with code, outputs and reasoning ↓Primary references
Explanations are authored by SecNet. References support method and platform context; verify current editions and organizational policy for real use.