Security best practices

The platform gives you the controls, and how you use them decides how well your projects are protected. This article collects the practices that matter most, grouped by what they protect. For what Bulutistan secures and what you secure, see Shared responsibility.

Protect sign-inCopy Anchor Link

• Turn on two-factor authentication for your account. Use an authenticator app, and keep your Recovery codes somewhere safe: they're shown once. See Set up two-factor authentication.
• Require it for existing members. An owner of the subscription turns on Enforce 2FA for all members in Identity & Access › Authentication. Existing members who don't have two-factor authentication are asked to set it up at their next sign-in. The requirement doesn't end sessions that are already open.
• Review your sessions. Active sessions in Identity & Access › Authentication lists every browser that's signed in to your account. If you don't recognize one, revoke it, or select Sign out everywhere else.

For example, after you turn on Enforce 2FA for all members, an existing member who signs in without two-factor authentication has to set it up before they reach the console. See Enforce two-factor authentication.

Grant the least privilegeCopy Anchor Link

• Choose the narrowest built-in role. Reader can only read. Contributor manages resources but can't change access or billing. Billing Operator manages only billing and budgets. Keep Owner for the few people who manage access and billing.
• Grant on the narrowest scope. Grant a role on a project rather than on the whole subscription when a person works in one project. When a built-in role gives too much, create a custom role.
• Remove people who leave. When you remove a member, their API tokens are revoked. See Deactivate, reactivate, or remove a member.

For example, a developer who deploys one application gets Contributor on that application's project, and no role anywhere else. See Use built-in and custom roles.

Keep credentials short-lived and narrowCopy Anchor Link

• Use service accounts for automation. A service account key acts with the service account's roles, not with a person's, and keeps working when the person who set it up leaves. A key always expires after 365 days. See Manage keys.
• Limit API tokens. Give each API token only the scopes that it needs, an expiry date, and, where the caller has fixed addresses, an IP allowlist.
• Store secrets safely. The platform shows a secret once. Keep secrets in a secrets manager, never in code or version control.
• Rotate, and revoke at once when in doubt. After you rotate an API token, the old secret keeps working for 24 hours, so you can update your callers. A revoked token stops working on its next request. See Rotate an API token.
• Treat application credentials the same way. An application credential for OpenStack tools belongs to one project and always expires. Choose a short lifetime, rotate it before it expires, and revoke it when you no longer need it. See Rotate and revoke credentials.

For example, a deployment pipeline uses a key of a service account that has Contributor on the staging project only, and the pipeline replaces the key before it expires. See Service accounts and API tokens.

Limit network exposureCopy Anchor Link

• Set a source on every inbound rule. The Quick security rules of the instance creation wizard open their ports to every address unless you change the source, and the console warns when SSH or RDP is open to the whole internet. Use My IP to fill in your current public address.
• Open only the ports that a workload needs. Remove rules that you no longer use.
• Restrict outbound traffic where it matters. A new security group allows all outbound traffic. Remove those rules and add narrower ones for instances that should reach only specific addresses.
• Give public addresses only where needed. Associate a Floating IP only with instances that must be reached from the internet. Reach the others through a Site-to-Site VPN tunnel from your own network.

For example, allow SSH to your instances only from your office's address range, and allow ports 80 and 443 from every address only on your web servers. See Create and edit security groups and rules.

Protect your dataCopy Anchor Link

• Back up the volumes that you need. Backup Center backs up only the volumes that you assign to a backup plan. Check regularly for volumes that no plan covers. See Find unprotected volumes.
• Turn on deletion protection. With Deletion protection on, the console and the REST API refuse to delete an instance or a volume until someone turns the protection off. See Turn deletion protection on or off for instances and Protect a volume for volumes.
• Take a snapshot before risky changes, such as an operating system upgrade. See Create volume snapshots.
• Encrypt sensitive data yourself where it must be encrypted at rest. See Encryption.

For example, before you upgrade the database on an instance, take a snapshot of its data volume, and keep deletion protection on for the instance and the volume.

Watch for changesCopy Anchor Link

• Review the Activity Log. Look for operations that you don't expect, for example deleted resources or changed role assignments. Records are deleted after a retention period, so export the ones that you need to keep. See Audit and activity records.
• Alert on what matters. Create alert rules for your important instances, and send notifications to a channel that your team watches. When you receive webhook notifications, check their signatures. See Create alert rules.

Related tasksCopy Anchor Link

• Enforce two-factor authentication
• Service accounts and API tokens
• Create and edit security groups and rules
• Create and manage backup plans