OpenShift and platform tools access control policy

---

5. Roles and responsibilities

5.1 Roles

Data custodian

The custodian for OpenShift and Platform Tools data who is an Authorized Approver for the Access Granter and Admin profiles, as well as infrastructure-controlled accounts.

Application manager

A staff member responsible for a given platform application.  They are also responsible for contents and accuracy of the Access Authorization Matrix, ensuring new Profiles are created when requested and authorized, as well as granting access when authorized by the Data Custodian.

Access granter

A staff member responsible for providing staff and/or contractors with access to OpenShift and Platform Tools.

Product owner

The individual responsible for the overall success of the OpenShift product, including staff oversight and funding acquisition.

5.2 Responsibilities

All personnel (employees, contractors, vendors and third parties) must abide by relevant Information Security and Access Control policies and procedures. All access must adhere to the least privilege principle.

All account holders must:

• Only use their account and access in accordance with the Appropriate Use Policy
• Secure their credentials in line with the BC Government Password Best Practices
• Be responsible for the systems, services, and data within their control
• Transfer services and data prior to vacating a role referring to the Departing or Transferring Employee Guide

All management must:

• Only sponsor access requests that have:
  • A documented request
  • Adequate and appropriate justification, based on the requester’s business need
  • Document all access request sponsorships

Asset owners must:

Ensure that periodic reviews of access to their assets are conducted and anomalies investigated. Review periods are based on the risk rating of a given asset.

Access granters must:

• Only grant access requests that have:
  • A documented request
  • Adequate and appropriate justification, as confirmed by the sponsor
  • Documented sponsorship and subsequent approval from relevant personnel
  • Document all access granted

6. Access control implementation

The following headings outline the principles around how access is managed on the B.C. Government OpenShift Container Platform.

6.1 Identity management

Formal user registration and de-registration processes are implemented to enable the assignment of identities and accounts on an individual basis. Approved external identity providers (IDPs) are acceptable and used (IDIR, GitHub, AzureAD).

This ensures accountability for all actions taken by employees, contractors and other third-party account users.

6.2 Authentication management

All account, service and platform access are managed through secure authentication controls.

Platform tools use the following types of accounts:

• IDIR or GitHub via KeyCloak
• IDIR via Azure AD
• Kubernetes service accounts
• Local tool admin accounts

6.2.1 Granting systems access

Only platform service staff or assigned system or project administrators should grant access to systems.  Contractors should NOT grant access to other users unless specifically instructed to do so and have been temporarily granted the capability.  This instruction must be documented and maintained for audit purposes.

6.2.2 Self-Provisioning systems access (don’t do it)

For systems where users are granted privileged roles that enable access granting, those users should NOT self-provision access for other accounts.  Requests for additional individual accounts must be submitted for review, and another individual should grant an appropriate access level.

6.2.3 Submitting access requests

All requests should be submitted via DevOps Requests.

No IDIR IDs should be entered through this request process, as exposure will result in an information incident. 

GitHub IDs, GitHub associated email address, or government email address are acceptable.

6.3 Access governance

A formal user access provisioning process is implemented to assign or revoke access rights for all user types to systems and information assets under the control of the BC Government and platform services team.

This access provisioning is based on the following principles:

• All requests for or changes to access are documented and tracked
• All access requests or changes require documented justification
  • Justification will be based on a simple risk assessment and the business need and will be confirmed by the request sponsor
  • Appropriate sponsorship & approval is required and documented for all access requests or changes
• All access changes granted by administrators are documented and tracked
  • All access requested will be granted according to the concept of least privilege, allowing only authorized accesses for users (and processes acting on behalf of users) which are necessary to accomplish assigned tasks in accordance with organizational goals and business functions
  • The requestor is responsible for requesting access according to the least privilege principle
• Reviews of access are performed by relevant asset owners periodically
• These principles are agnostic of account type, service, application or system

6.4 Privileged account management

Privileged accounts and privileged access must be purpose driven, secure and always adhere to the principle of least privilege.

6.4.1 Privileged platform access for community partners

In certain situations, community partners may be granted privileged access to the platform. This can occur for several reasons, including specific platform tooling expertise and platform services staff workload.

This type of access must be approved by either one of the following positions:

• Product Director, DevOps Container Platform
• Sr Director, DevOps Platform Services
• Executive Director, DevOps and Cloud Services

Privileged platform access must be reviewed on a monthly basis and removed if no longer required.

6.5 Removal or adjustment of access rights

The access rights of all employees, contractor and service account users to information and information processing facilities will be removed upon termination of their employment, contract or agreement on adjusted upon change.

For all Government employees, this is managed through the PSA onboarding and exit processes.

Additional access to accounts, assets, systems or services are subject to review and approval on a case-by-case basis, as outlined in the Access Governance section above.

6.6 Access reviews and reporting

Access to assets, services and systems will be periodically reviewed. The frequency of these reviews depends on the identified risk surrounding the asset and access in question.

1. Where user access is no longer required, supervisors are required to request cancellation of access to coincide with the employee’s last working day
2. Where a user is on temporary leave (more than 3 months leave), access should be disabled within five (5) business days
3. Access should be deleted within five (5) business days upon notice that the assigned user access is no longer required.

Where an access review identifies an access anomaly it will be treated as a potential incident and investigated by the asset owner and information security team(s). Reference the OCIO Information Incident Management process.

6.7 Access in special circumstances

There are special circumstances where extra or privileged access is needed. For all cases to access to an account, the information contained within an account or information pertaining to the activity of an account, is carefully restricted and must only be carried out with the appropriate authorization and safeguards in place.

Appendix A below outlines the approach taken for special circumstances.

---

7. Supporting information security policies, procedures and guidance

Review supporting information security policies for the principles listed above.

Review the B.C. Government Information Security Incident Reporting page. 

---

Appendix A – Access in special circumstances

Special circumstances include, but are not limited to:

---

Appendix B – GitHub organizations

GitHub organizations

The DevOps and Cloud Services Platform Services team manages 2 GitHub organizations.

Permissions

Possible Base permission sets include:

The base permissions currently set on our GitHub organizations are as follows:

Audit logs for GitHub organizations should be reviewed at minimum every 6 months.

Team membership for GitHub repositories should be reviewed at minimum every 3 months.

Organizational access for GitHub Organizations managed by the Platform Services team will be limited to Platform Services staff. Temporary access may be granted to staff/contractors outside of the Platform Services team in line with 6.7 Access in Special Circumstances.

GitHub enterprise – managed user

GitHub Enterprise is implemented using the Managed User setup which integrates with Azure Active Directory (Azure AD).

Each user account in GitHub Enterprise requires a license, which can be procured through an iStore request. Microsoft Visual Studio licenses include a GitHub Enterprise license.

Once a license is obtained, a request to the Digital Office Developer Experience team can be made for access to a specific enterprise organization or set of repositories.

It’s recommended that each Ministry maintain a centrally managed security group for GitHub Enterprise licensed users. This will automatically provision user access through Azure AD into our GitHub Enterprise space. Then organization owners/administrators can assign specific access to repositories.

---

Appendix C – Platform tools access

OpenShift consoles

• https://console.apps.clab.devops.gov.bc.ca/k8s/cluster/projects
• https://console.apps.klab.devops.gov.bc.ca/k8s/cluster/projects
• https://console.apps.silver.devops.gov.bc.ca/k8s/cluster/projects
• https://console.apps.gold.devops.gov.bc.ca/k8s/cluster/projects
• https://console.apps.klab2.devops.gov.bc.ca/k8s/cluster/projects
• https://console.apps.emerald.devops.gov.bc.ca/k8s/cluster/projects

Requirements

• GitHub account, 2FA enabled
  • Member of BCDevOps GitHub Org (added by the platform services team during onboarding)
• Azure AD IDIR account, MFA active

Namespace admins are assigned as part of the onboarding process through the registry.

Users can be granted many roles using role-binding. Due to the number of role bindings available, they are not described here. Role bindings may be made in a variety of ways within a project by any admin user:

• via Administrator view (GUI)
  • Developer view (GUI)
  • via the API as distinct commands or
  • via .yml files applied via the CLI

Additional details on OpenShift Access and RBAC can be found here:

• Provision a new OpenShift project
• Grant user access in OpenShift

Platform Product Registry (IDIR)

• Administrator
• Product Owner
• Technical Contact

KeyCloak (IDIR)

• Master Realm Administrator
• Realm Administrator
• Realm Viewer

Additional details on KeyCloak can be found here:

• https://github.com/bcgov/ocp-sso/wiki
• https://github.com/bcgov/ocp-sso

Artifactory (Service Account)

• Admin
• Service Account
  • This is automatically provisioned to a project namespace.  Service account name and credential can be found in the OpenShift console:
    • Administrator View: Workloads > Secrets.
    • Developer View: Secrets

Additional details on Artifactory can be found here:

• https://github.com/BCDevOps/developer-experience/tree/master/apps/artifactory/artifactory-operator

Sysdig Monitor (GitHub)

• Admin
• Project (MANAGER, TEAM_READ, TEAM_EDIT, TEAM STANDARD)

Additional details on Sysdig Monitor can be found here:

• Sysdig monitor onboarding

Rocket.Chat (GitHub, IDIR) – Chat.developer.gov.bc.ca

• There are many roles described in the Roles Matrix in Appendix B
• Access is via GitHub account or IDIR

Explore details on access.

Vault (Service Account)

• Admin
  • Master administrative account for Vault service
• Service Account
  • A separate service account is created for each OpenShift namespace
  • Service account name and credential can be found in the OpenShift console:
    • Administrator View: Workloads > Secrets
    • Developer View: Secrets

• Azure Key Vault
  • Setup and configured by the Cloud Pathfinder team under the BCGov tenancy on Azure Canada.  Used as part of Vault unseal process using GitOps
• Terraform Cloud
  • Setup and configured by the Cloud Pathfinder team.  Used as part of GitOps provisioning

ACS (GitHub, Azure AD IDIR)

• None
  • The default role assigned. This provides no access
• Admin
  • Read/write access to all capabilities and manage user access
• Analyst
  • Read access to all content
• Continuous Integration
  • Permissions required to enforce deployment policies
• Ministry Admin
  • Scoped permissions for Ministry staff that shouldn’t be able to affect overall platform settings
• Namespace Admin
  • A user that is an administrator of one or more namespaces across various clusters
• The following roles are not assigned in isolation currently (capabilities included in above roles):
  • Scope manager
  • Sensor creator
  • Vulnerability management approver
  • Vulnerability management requestor
  • Vulnerability report creator 

---

Appendix D – Role profile summary

Below is a summary of the current Profiles available for informational purposes only.