Access and Security

What is Access and Security in cloud hosting?

Access and Security refers to the set of controls and mechanisms that determine who can access your cloud resources and what actions they can perform. It combines identity management, authentication methods, authorization rules, and protective measures to prevent unauthorized access while enabling legitimate users to interact with your infrastructure.

In cloud environments, Access and Security encompasses multiple layers including user authentication (proving who you are), authorization (defining what you can do), network access controls (controlling traffic flow), and resource-level permissions (governing specific actions on individual resources). InMotion Cloud implements this through OpenStack-based security controls that default to blocking all external access until you explicitly define what traffic your network will allow for each individual host.

Why Access and Security exists

Without structured Access and Security controls, cloud environments would be vulnerable to unauthorized access, data breaches, and resource misuse. Anyone could access any resource, modify configurations, delete data, or consume resources without accountability.

Access and Security solves this by creating clear boundaries around who can do what, when, and from where. It prevents accidental or malicious actions that could disrupt services, expose sensitive data, or incur unexpected costs. It also provides audit trails for compliance and troubleshooting.

What does Access and Security actually do?

Blocks all external network access by default until you explicitly allow specific traffic patterns (InMotion Cloud's secure-by-default architecture)
Authenticates users and services before granting access to cloud resources using Role-Based Access Control (RBAC) in OpenStack
Enforces authorization policies that define which actions specific users or roles can perform
Segregates cluster traffic at the networking level with entirely private virtual networks per VPC
Restricts network traffic to and from cloud resources based on security group rules you configure per-instance
Encrypts data in transit using protocols like SSH and TLS to prevent eavesdropping
Logs authentication attempts and access events for security monitoring and compliance
Implements multi-factor authentication to add an additional verification layer beyond passwords
Gives you full governance and control over hardware access, including when the cloud provider can access your cluster
Applies the principle of least privilege by granting only the minimum permissions required

When would I use Access and Security?

You need Access and Security controls in every cloud deployment. When you launch an instance, you configure SSH key pairs to control who can log in. When you create a database, you set firewall rules to restrict which IP addresses can connect. When you add team members, you assign roles that determine which resources they can manage.

Use Access and Security when multiple users need different levels of access. A developer might need read-only access to production resources while maintaining full control in development environments. An operations team might need the ability to restart instances but not delete them.

Access and Security is critical for compliance requirements. Industries like healthcare, finance, and government mandate specific security controls, audit trails, and access restrictions. Properly configured Access and Security helps you meet these regulatory obligations.

When would I NOT use Access and Security?

You never skip Access and Security entirely in production cloud environments. However, you might temporarily disable certain controls in isolated development or testing environments where the risk is minimal and convenience outweighs security concerns.

In completely air-gapped or offline systems with no network connectivity, some network-based Access and Security controls become irrelevant. A server with no network interface does not need firewall rules, though local authentication still matters.

Overly restrictive Access and Security can hinder legitimate work. If security groups block necessary traffic or permissions are too limited, users cannot complete their tasks. The goal is to balance security with usability, not to lock down everything indiscriminately.

Real-world example

Company A runs an e-commerce platform on InMotion Cloud with a web application, API servers, and a database. When they first provision their VPC, InMotion Cloud's secure-by-default architecture blocks all external access automatically. Company A then explicitly defines their security posture by creating separate security groups for each tier.

They configure the web tier security group to accept HTTPS traffic on port 443 from any IP address but block all other inbound traffic including SSH. For SSH access, they create a separate security group rule allowing port 22 only from their corporate VPN IP range. The API tier security group only accepts traffic from the web tier's private IP range. The database tier security group only accepts PostgreSQL connections on port 5432 from the API tier.

Company A uses OpenStack's RBAC to assign permissions. Developers get the "Member" role in the development project with full control over instances and networks. In production, developers only get read-only permissions. The operations team gets the "Admin" role in production but cannot access application code or database contents. Each team member authenticates with SSH key pairs that rotate every 90 days.

Company A benefits from InMotion Cloud's network segregation. Their VPC traffic runs on entirely private virtual networks isolated from other customers. They configure their router to log all traffic entering and leaving their VPC, creating an audit trail for compliance reviews.

Frequently Asked Questions

Can I have different Access and Security settings for different resources?

Yes, each resource can have its own Access and Security configuration. A web server might allow public HTTPS access while a database server accepts connections only from specific IP addresses. You apply security groups per-instance and configure permissions per-user or per-role. This granular control lets you implement defense in depth where different security layers protect different components.

What happens if I lock myself out by misconfiguring Access and Security?

If you block your own access through incorrect firewall rules or lost SSH keys, you may lose the ability to connect to your instances. Most cloud providers offer console access through their web dashboard as a backup method to regain access. You can then correct the misconfiguration from the console. This is why you should test security changes carefully and maintain backup access methods before applying restrictive rules.

Do I need to update Access and Security settings when I scale my infrastructure?

Yes, as you add more instances or change your architecture, you must adjust Access and Security accordingly. New instances need appropriate security groups. New team members require user accounts and permissions. Changing application tiers may require modifying firewall rules to allow new traffic patterns. Regularly review Access and Security configurations to ensure they match your current infrastructure and business needs.

How do I know if my Access and Security is working correctly?

Test your Access and Security by attempting actions from different user accounts and network locations. Verify that allowed traffic succeeds and blocked traffic fails. InMotion Cloud's secure-by-default approach means you should confirm that all traffic is blocked unless you have explicitly allowed it. Review authentication logs in OpenStack Horizon for suspicious login attempts. Use security scanning tools to identify open ports or misconfigurations. Regular security audits and penetration testing help validate that your controls function as intended.

Can the cloud provider access my resources?

With InMotion Cloud, you have full control over when the provider can access your cluster hardware. This privacy-first architecture means you dictate hardware access permissions. Your VPC runs on segregated networking with entirely private virtual networks isolated from other customers. This approach differs from some hyperscalers where the provider maintains backend access to your infrastructure. You control your data governance completely.

Can Access and Security affect application performance?

Properly configured Access and Security has minimal performance impact. Evaluating firewall rules or checking permissions adds negligible overhead compared to network latency or application processing time. However, overly complex security group rules with thousands of entries or frequent authentication against slow external identity providers can introduce delays. Keep security rules simple and use local caching for authentication results when possible to maintain performance.

Summary

Access and Security controls who can access your cloud resources and what actions they can perform through authentication, authorization, and network controls.
OpenStack's Role-Based Access Control (RBAC) organizes permissions by job role, while InMotion Cloud's privacy-first approach gives you full governance over when the provider can access your cluster hardware.
Every cloud environment requires Access and Security configuration including security groups, SSH key pairs, user permissions, and network access rules applied per-instance and per-role.
Balance security with usability by applying the principle of least privilege without blocking legitimate work, and regularly test your configurations to ensure they match your infrastructure needs.

Related terms

These cloud-specific concepts work together with Access and Security:

Security Group: A set of firewall rules that controls inbound and outbound network traffic to cloud resources, such as allowing SSH access on port 22 or HTTPS traffic on port 443.
SSH Key Pair: A cryptographic authentication method using public and private keys to securely access instances, such as connecting to a Linux server without passwords.
Router: A network component that directs traffic between subnets and external networks, such as connecting your VPC to the internet or routing traffic between isolated network segments.
Instance: A virtual machine running in the cloud where your applications execute, such as a web server or database host.
VPC (Virtual Private Cloud): An isolated network environment where you launch and manage cloud resources with full control over IP addressing and network topology, such as a private network segment for production workloads.