How to update GCP credentials in the YBA Cloud Provider – Yugabyte

Environment:

Yugabyte Anywhere (YBA): Earlier than 2025.1.4.0, 2024.2.9.0 and 2025.2.3.0

Issue:

When attempting to update credentials for an active GCP provider in YugabyteDB Anywhere (YBA), users may encounter the following error even when the Shared VPC Project field has not been changed:

Edit provider request failed: Shared VPC Project cannot be modified for in-use providers.

Cause:

The provider edit validation logic does not distinguish between a Shared VPC Project change and a credential file update. When any edit is submitted for an in-use GCP provider, the validator raises a blanket block, even if the Shared VPC Project field is untouched. This means credential rotation (a routine operation) is incorrectly prevented on any provider that has live universes attached.

Resolution:

Step 1: Confirm the Error and Check Provider Status

Verify the provider has active universes attached and that the error is reproducible:

grep -i "Shared VPC Project cannot be modified" /opt/yugabyte/yugaware/data/logs/application.log*

From the YBA database, confirm universe associations:

Refer How to login into YugabyteDB Anywhere database to login into YBA database

SELECT p.uuid, p.name, p.code,
       COUNT(u.universe_uuid) AS universe_count
FROM provider p
LEFT JOIN universe u ON u.provider_id = p.uuid
WHERE p.code = 'gcp'
GROUP BY p.uuid, p.name, p.code;

Step 2: Identify the Provider's Shared VPC Configuration

Confirm whether a Shared VPC (use_host_vpc) is actually configured, to rule out a legitimate block:

SELECT uuid, name,
       pgp_sym_decrypt(details, 'provider::details')::json->'gce_project'   AS gce_project,
       pgp_sym_decrypt(details, 'provider::details')::json->'use_host_vpc'  AS use_host_vpc,
       pgp_sym_decrypt(details, 'provider::details')::json->'host_vpc_id'   AS host_vpc_id
FROM provider
WHERE code = 'gcp';

If use_host_vpc is false or null and you are not changing host_vpc_id, this confirms the validation is a false positive.

Step 3: Apply a Workaround

Warning: Direct database modifications carry risk. Always back up the database first and validate in a non-production environment before applying to production.

3a. Back up the provider table:

CREATE TABLE provider_backup_YYYYMMDD AS
SELECT * FROM provider WHERE code = 'gcp';

3b. Retrieve the current provider details:

SELECT uuid, name,
       pgp_sym_decrypt(details, 'provider::details') AS current_details
FROM provider
WHERE code = 'gcp' AND name = 'YOUR_PROVIDER_NAME';

3c. Update the credential file path:

UPDATE provider
SET details = pgp_sym_encrypt(
    jsonb_set(
        pgp_sym_decrypt(details, 'provider::details')::jsonb,
        '{gce_application_credentials}',
        '"/path/to/new/credential.json"'::jsonb
    )::text,
    'provider::details'
)
WHERE uuid = 'PROVIDER_UUID';

3d. Verify the update:

SELECT uuid, name,
       pgp_sym_decrypt(details, 'provider::details')::json->'gce_application_credentials' AS credentials_path
FROM provider
WHERE uuid = 'PROVIDER_UUID';

3e. Restart YBA to apply changes:

sudo systemctl restart yb-platform

Step 4: Validate Recovery

After applying any of the above options, confirm the provider is healthy:

In the YBA UI, navigate to Configs > Cloud Provider Configuration > GCP and verify the provider shows no errors.
Confirm universes remain reachable and healthy.
Re-attempt a test credential update through the UI to verify the fix took effect.

Refrence ID: SUPPORT-888