mirror of
https://github.com/hanzoai/kms.git
synced 2026-10-17 11:18:16 +00:00
zeekay
0ebffbd529
- Fix 381 files where branding script corrupted variable names (e.g. isHanzo KMSTemplate -> isKmsTemplate) - Rebrand from "Hanzo KMS" to just "KMS" for white-label support (allows Lux KMS, Hanzo KMS, etc. via configuration) - 856 files, purely string replacements, no logic changes
52 lines
4.4 KiB
Plaintext
52 lines
4.4 KiB
Plaintext
---
|
||
title: "Overview"
|
||
description: "Learn more and understand the concept of KMS projects."
|
||
---
|
||
|
||
## Projects
|
||
|
||
A project defines a specific scope of work for a given product line in KMS.
|
||
|
||
Projects are created within an [organization](/documentation/platform/organization), and an organization can contain multiple projects across different product types.
|
||
|
||
## Project Types
|
||
|
||
KMS supports project types, each representing a different security product with its own dashboard, workflows, and capabilities.
|
||
|
||
|
||
|
||
The supported project types are:
|
||
|
||
- [Secrets Management](/documentation/platform/secrets-mgmt/overview): Securely store, access, and distribute secrets across environments with fine-grained controls, automatic rotation, and audit logging.
|
||
- [Secrets Scanning](/documentation/platform/secret-scanning/overview): Detect hardcoded secrets in code, CI pipelines, and infrastructure—integrated with GitHub, GitLab, Bitbucket, and more.
|
||
- [KMS PKI](/documentation/platform/pki/overview): Issue and manage X.509 certificates using protocols like EST, with support for internal and external CAs.
|
||
- [KMS KMS](/documentation/platform/kms/overview): Encrypt and decrypt data using centrally managed keys with enforced access policies and full audit visibility.
|
||
- [KMS PAM](/documentation/platform/pam/overview): Manage access to resources like databases, servers, and accounts with policy-based controls and approvals.
|
||
|
||
## Roles and Access Control
|
||
|
||
[Users](/documentation/platform/identities/user-identities) and [machine identities](/documentation/platform/identities/machine-identities) must be added to a project to access its resources. Each identity is assigned a [project-level role](/documentation/platform/access-controls/role-based-access-controls#project-level-access-controls) that defines what they can manage—such as secrets, certificates, or PAM access. These roles apply to both individuals and [user groups](/documentation/platform/groups), enabling scalable access across teams and environments.
|
||
|
||
Project access is strictly scoped: only members of a project can view or manage its resources. If someone needs access but isn’t part of the project, they can submit an access request.
|
||
|
||
Each project in KMS has its own [access control model](/documentation/platform/access-controls/role-based-access-controls#project-level-access-controls), distinct from [organization-level access control](/documentation/platform/access-controls/role-based-access-controls#organization-level-access-controls). While organization roles govern broader administrative access, project-level roles control what users, groups, and machine identities can do within the boundaries of a specific project—such as managing secrets, issuing certificates, or configuring PAM access.
|
||
|
||
Depending on the project type (e.g. Secrets Management, PKI, PAM), project-level access control supports advanced features like [temporary access](/documentation/platform/access-controls/temporary-access), [access requests](/documentation/platform/access-controls/access-requests), and [additional privileges](/documentation/platform/access-controls/additional-privileges).
|
||
|
||
|
||
|
||
To learn more about how permissions work in detail, refer to the [access control documentation](/documentation/platform/access-controls/overview).
|
||
|
||
## Audit Logs
|
||
|
||
KMS provides [audit logging](/documentation/platform/audit-logs) at the project level to help teams monitor activity and maintain accountability within a specific project. These logs capture all relevant events—such as secret access, certificate issuance, and PAM activity—that occur within the boundaries of that project.
|
||
|
||
Unlike the organization-level audit view, which aggregates logs across all projects in one centralized interface, the project-level audit view is scoped to a single project. This enables relevant project admins and contributors to review activity relevant to their work without having broader access to audit logs in other projects that they are not part of.
|
||
|
||
## Project Settings
|
||
|
||
Each project has its own settings panel, with options that vary depending on the selected product type. These may include
|
||
setup and configuration for environments, tags, behaviors, encryption strategies, and other options.
|
||
|
||
Project settings are fully independent and reflect the capabilities of the associated product.
|