🛡️ Google Project has API Keys🟢

• Contextual name: 🛡️ Google Project has API Keys🟢
• ID: /ce/ca/google/project/api-keys-for-active-services
• Tags:
  • 🟢 Policy with categories
  • 🟢 Policy with type
  • 🟢 Production policy
• Policy Type: COMPLIANCE_POLICY
• Policy Categories: SECURITY

Logic

• 🧠 prod.logic.yaml🟠🟢
  • 📗 Google Project
  • 🧪 test-data.json

Similar Policies

• Cloud Conformity: API Keys Should Only Exist for Active Services

Description

Open File

Description

API keys should only be used for services when other authentication methods are unavailable. Unused keys with their permissions intact may still exist within a project. Keys are insecure because they can be viewed publicly, such as from within a browser, or accessed on a device where the key resides. It is recommended to use the standard authentication flow instead.

Rationale

To avoid the security risk of using API keys, it is recommended to use the standard authentication flow instead. Security risks involved in using API keys include:

• API keys are simple encrypted strings
• API keys do not identify the user or the application making the API request
• API keys are typically accessible to clients, making it easy to discover and steal an API key

Impact

Deleting an API key will break dependent applications (if any).

Audit

From Console

1. From within the project you want to audit, go to APIs & Services\Credentials.
2. In the section API Keys, no API key should be listed.

From Google Cloud CLI

... see more

Remediation

Open File

Remediation

From Google Cloud Console

1. Go to APIs & Services\Credentials.
2. In the API Keys section, delete API keys by clicking the Delete icon in front of each API Key Name.

From Google Cloud CLI

1. Run the following from within the project you want to audit:

   gcloud services api-keys list \
       --filter={{filter}}

2. Pipe the results into:

   gcloud alpha services api-keys delete {{api-key-id}}

policy.yaml

Open File

Linked Framework Sections

Section	Sub Sections	Internal Rules	Policies	Flags	Compliance
💼 CIS GCP v2.0.0 → 💼 1.12 Ensure API Keys Only Exist for Active Services - Level 2 (Automated)			1		no data
💼 CIS GCP v3.0.0 → 💼 1.12 Ensure API Keys Only Exist for Active Services - Level 2 (Automated)			1		no data
💼 Cloudaware Framework → 💼 Credential Lifecycle Management			28		no data
💼 FedRAMP High Security Controls → 💼 PL-8 Security and Privacy Architectures (L)(M)(H)			3		no data
💼 FedRAMP High Security Controls → 💼 SA-8 Security and Privacy Engineering Principles (L)(M)(H)			6		no data
💼 FedRAMP Low Security Controls → 💼 PL-8 Security and Privacy Architectures (L)(M)(H)			3		no data
💼 FedRAMP Low Security Controls → 💼 SA-8 Security and Privacy Engineering Principles (L)(M)(H)			6		no data
💼 FedRAMP Moderate Security Controls → 💼 PL-8 Security and Privacy Architectures (L)(M)(H)			3		no data
💼 FedRAMP Moderate Security Controls → 💼 SA-8 Security and Privacy Engineering Principles (L)(M)(H)			6		no data
💼 ISO/IEC 27001:2022 → 💼 8.27 Secure system architecture and engineering principles		1	4		no data
💼 NIST CSF v1.1 → 💼 PR.IP-2: A System Development Life Cycle to manage systems is implemented		6	9		no data
💼 NIST CSF v2.0 → 💼 ID.AM-03: Representations of the organization's authorized network communication and internal and external network data flows are maintained			89		no data
💼 NIST CSF v2.0 → 💼 ID.AM-08: Systems, hardware, software, services, and data are managed throughout their life cycles			27		no data
💼 NIST CSF v2.0 → 💼 ID.IM-01: Improvements are identified from evaluations			45		no data
💼 NIST CSF v2.0 → 💼 ID.IM-02: Improvements are identified from security tests and exercises, including those done in coordination with suppliers and relevant third parties			59		no data
💼 NIST CSF v2.0 → 💼 ID.IM-03: Improvements are identified from execution of operational processes, procedures, and activities			60		no data
💼 NIST CSF v2.0 → 💼 PR.DS-10: The confidentiality, integrity, and availability of data-in-use are protected			184		no data
💼 NIST CSF v2.0 → 💼 PR.IR-03: Mechanisms are implemented to achieve resilience requirements in normal and adverse situations			21		no data
💼 NIST SP 800-53 Revision 5 → 💼 PL-8 Security and Privacy Architectures	2		3		no data
💼 NIST SP 800-53 Revision 5 → 💼 SA-8 Security and Privacy Engineering Principles	33		8		no data
💼 PCI DSS v3.2.1 → 💼 2.1 Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network.	1		11		no data
💼 PCI DSS v3.2.1 → 💼 6.3 Develop internal and external software applications securely.	2		4		no data
💼 PCI DSS v4.0.1 → 💼 2.2.2 Vendor default accounts are managed.			11		no data
💼 PCI DSS v4.0.1 → 💼 6.2.1 Bespoke and custom software are developed securely.			3		no data
💼 PCI DSS v4.0 → 💼 2.2.2 Vendor default accounts are managed.			11		no data
💼 PCI DSS v4.0 → 💼 6.2.1 Bespoke and custom software are developed securely.			3		no data