Owner: Architect:

Francesco Ilario

Story (Required)

As a Primaza Developer, I would like to have Roles to bind to Agents identities in Primaza namespace so that Primaza can give to agents permissions on its resources.

Background (Required)

As defined in the Primaza architecture document, Agents should be able to report to Primaza.
When an application or service namespace is initialized on a Worker cluster, an identity is created on Primaza cluster to provide to the agents (cfr. APPSVC-1283).

Roles to bind to Service and Application agents identities need to exists in Primaza's namespace.

See epic for arch document link.

Glossary

See glossary in architecture document

Out of scope

• Roles Binding

In Scope

• Role for Service agents
• Role for Application agents

Approach(Required)

When Primaza is installed in the cluster the Roles to bind to agents identities must be created in Primaza's namespace.
We need one role for Service Agents and one for Application Agents.
They may be named primaza-service-agent and primaza-application-agent.

Service Agent Role should have the following permissions:

- apiGroup: primaza.io/v1alpha1
  resource: RegisteredServices
  verbs: 
  - create
  - update

Application Agent Role should have the following permissions:

- apiGroup: primaza.io/v1alpha1
  resource: RegisteredServices/status
  verbs: 
   - update
   - get
- apiGroup: primaza.io/v1alpha1
  resource: ServiceClaim
  verbs: 
   - create
   - update
- apiGroup: primaza.io/v1alpha1
  resource: ServiceClaim/status
  verbs: 
   - get
   - create
   - update

Demo requirements(Required)

NA

Dependencies

NA

Edge Case

NA

BDD Tests

You can find BDD Test specification for this story in the "Testing Instruction" Field Tab or in the GitHub Issue linked to this story.
Click here for all BDD Tests Issues.

Acceptance Criteria

• Development
  Agents roles are part of Primaza's manifests

• QE

• Docs
  There is a section in Agents page in our docs dedicated to explaining what roles are assigned to Agents
  Update architecture document with any changes while implementing

INVEST Checklist

Dependencies identified
Blockers noted and expected delivery timelines set
Design is implementable
Acceptance criteria agreed upon
Story estimated

Legend

Unknown
Verified
Unsatisfied