Skip to main content

Offboarding DevOps Accelerator

Problem​

  • Your company is ready to take over all operations and needs to restrict DevOps Accelerator’s access to mission-critical environments for regulatory compliance (e.g. for HIPAA compliance).

  • Your engagement with DevOps Accelerator is coming to an end and you need to shut down entirely DevOps Accelerator’s access to all environments or you are pausing the engagement

  • DevOps Accelerator has access to multiple systems and you may want to restrict access accordingly.

Solution​

AWS​

Option 1: Restrict Federated IAM Access to Some Accounts​

Option 2: Restrict Federated IAM Access to a Single Account​

Option 3: Disable Federated IAM Access to All Accounts​

info

After disabling all Federated IAM access, you have the option to issue DevOps Accelerator team members SSO access via your own IdP.

Option 4: Issue IAM User Accounts​

caution

We strongly discourage this approach as it’s generally an anti-pattern to bypass SSO and introduces new requirements for offboarding team members.

Customer managed IdP​

For things like Okta, Workspaces, or Azure AD:

  • Remove DevOps Accelerator team members from your IdP.
  • Remove any test accounts that were used for evaluating teams/groups.

GitHub​

Typically customers provision a “DevOps Accelerator” team within their GitHub org.

Option 1: Revoke All Access​

Revoking this team’s access from repositories should be sufficient to remove all of our access. Also, ensure that any repositories do not have DevOps Accelerator usernames directly added as external contributors. This happens if repositories were created by our team in your organization.

Option 2: Downgrade Access​

Changing our team’s access to read-only will enable us to still participate in Code Reviews.

--img src="-assets-refarch-cleanshot-2022-02-25-at-17.05.51-20220225-230814.png" />

Spacelift​

Depending on how Spacelift was configured, make sure the LOGIN policy does not include any DevOps Accelerator users.

Go to https://<your-instance>.app.spacelift.io/policies

Then remove our team’s access or any hardcoded usernames.

Also, make sure to sign out any logged in sessions, by going to https://<your-instance>.app.spacelift.io/settings/sessions

--img src="-assets-refarch-cleanshot-2022-02-25-at-17.13.52-20220225-231427.png" />

--img src="-assets-refarch-image-20220225-231603.png" />

--img src="-assets-refarch-cleanshot-2022-02-25-at-17.18.20-20220225-231906.png" />

Slack​

Leave Channels Open

We recommend keeping open channels of communication between our teams. That way we are able to help you out in a pinch.

All customer channels are managed via Slack Connect. Some channels may be owned by your team, others by our team. If you desire to close the connection, ask your Slack administrator to remove our organization from the slack connection.

See:

Datadog/New Relic​

Offboard any @oceansoft.io email addresses.

OpsGenie​

Offboard any @oceansoft.io email addresses.

Customer Jira & Confluence​

Some customers have added our team directly to their Atlassian products. Make sure to offboard any @oceansoft.io email addresses.

1password​

1Password vaults may be shared between our teams. Sometimes customers add DevOps Accelerator to their vaults, other times customers were added to vaults controlled by DevOps Accelerator.

At the end of an engagement, we recommend to stop sharing vaults.

Customer Managed Vaults​

If your company controls the vault, simply remove DevOps Accelerator's team access from the vault. We recommend rotating all credentials both as an exercise and as an extra precaution.

DevOps Accelerator Managed Vaults​

When vaults are controlled by DevOps Accelerator, we require the customer to take over ownership by creating their own vault, and manually copying over the secrets.

  • Create a new vault for your team
  • Recreate all the credentials in the new vault. We recommend rotating credentials.
  • Share the new vault with your team
  • Request DevOps Accelerator destroy it's vault