IBM Cloud VPC Security Group References: Access by Membership, Not CIDR

The short answer

In IBM Cloud VPC, a security group rule can name another security group as its remote instead of a CIDR block. The rule then matches traffic from any network interface that is a member of that group. Add an instance to the referenced group and it gains access; remove it and access disappears. No rule edit, no IP list to maintain.

This is the right pattern for tier-to-tier access inside one VPC - web to app, app to database - where the set of clients is defined by role rather than by address. CIDR-based rules remain the right choice for sources outside the VPC: on-premises networks, partner ranges, or anything that has no group membership to reference.

How the mechanism works

A security group in IBM Cloud VPC is a set of allow rules attached to network interfaces, not to subnets. Each rule has a direction (inbound or outbound), a protocol, a port range, and a remote. The remote is either a CIDR block or a security group.

When the remote is a security group, evaluation is about identity rather than address. A packet arriving at the target interface is allowed if the sending interface belongs to the referenced group. Membership is checked when the connection is established, so attaching or detaching an interface changes effective access without touching the rule.

Two properties matter for troubleshooting:

• Stateful. Once a flow is allowed, return traffic is permitted automatically. You do not need a matching outbound rule for the reply. This also means a security group cannot be used to block the response side of an allowed connection.
• Allow-list only. There is no explicit deny rule. Anything not matched by an allow rule is dropped by default, and you cannot write a rule that overrides a broader allow.

A worked example: database access from a web tier

Suppose a web tier should reach a PostgreSQL database on TCP 5432, and both tiers live in the same VPC. Create two security groups - call them sg-web and sg-db - then add one inbound rule to sg-db whose remote is sg-web.

The rule itself is the interesting part. With the IBM Cloud CLI and the VPC infrastructure plug-in installed, targeted at the right region and resource group, the shape of the command is:

ibmcloud is security-group-rule-add sg-db inbound tcp \
  --port-min 5432 --port-max 5432 \
  --remote sg-web

Treat the flag names as illustrative rather than guaranteed. Run ibmcloud is security-group-rule-add --help in your own account before using this, because the CLI accepts identifiers as well as names in some positions and plug-in flags have changed over time. If your account resolves names ambiguously, substitute the security group IDs.

Then attach the groups to interfaces:

1. Attach sg-web to the network interfaces of the web instances.
2. Attach sg-db to the network interfaces of the database instances.
3. Confirm the database instance has no other inbound rule that already opens 5432 to a wider range - a broad CIDR rule would make the new rule's effect invisible during testing.

Note what the rule does not do. It does not grant access to every instance that could be described as "web"; it grants access to instances whose interfaces carry sg-web. An instance with the right name and the wrong group attachment is still blocked. That is the most common source of confusion with this pattern.

Limits worth checking before you design around it

Constraint	What it means in practice
Same VPC and region	A rule cannot reference a security group in another VPC or region. Cross-VPC traffic needs a different mechanism, such as a VPC connectivity option plus CIDR-based rules.
Quotas	Accounts have limits on security groups per VPC, rules per group, and rules per interface. Check current values with ibmcloud is quotas or the console quotas page rather than assuming a number.
Egress direction	Rules are directional. If the client's outbound traffic is restricted, the reference rule on the target does not help on its own.
No deny rules	You cannot carve an exception out of an allow. Narrow the allow instead, or use network ACLs for subnet-level filtering.
Network ACLs are separate	ACLs are stateless and apply at the subnet boundary. A connection can be allowed by a security group and still dropped by an ACL, or the reverse.

Common mistakes

• Writing CIDR rules out of habit. If the client set is defined by role and lives in the same VPC, a group reference is less brittle. CIDR rules are for sources that genuinely have no group membership.
• Assuming the reference grants access on its own. The client interface must actually carry the referenced group. Verify the attachment, not just the rule.
• Expecting cross-VPC references to work. They do not. Plan the boundary before building the rule set.
• Debugging with the wrong mental model of stateful traffic. If return packets flow without a matching outbound rule, that is expected. If you want stateless filtering, that is what network ACLs are for.
• Deleting a group that other rules reference. This is a state change with dependents. Check the effect on referencing rules in a non-production VPC first.

Verifying the result

Three checks, in order, will tell you whether the rule is doing what you think:

1. Inspect the rule. In the console, go to VPC > Security groups, select the target group, and look at the rules list. The Remote column should show the referenced group's name or ID, not a CIDR. From the CLI, list the rules for the group - ibmcloud is security-group-rules <security-group-id> - and confirm the remote field.
2. Test from a member. From an instance that carries the referenced group, run nc -vz <target-ip> <port> or your usual connection test. A success here plus a failure from an instance without the group is the evidence you want.
3. Check the logs. VPC flow logs and IBM Cloud Activity Tracker can confirm allowed and denied patterns after the change, which matters when the test host is not representative of production traffic.

If you need to undo the change, delete the rule by its ID rather than deleting the security group - the group may be attached to interfaces and referenced elsewhere. Confirm the delete command's syntax with --help before running it, and re-run the connectivity test afterwards to confirm the port is closed from the previously allowed source.

When to reach for something else

Security group references solve the "who is allowed" problem for traffic inside one VPC. They do not solve routing, cross-VPC reachability, or subnet-level filtering. If the requirement is "only these subnets may talk to these subnets," network ACLs express it. If the requirement is "only this service identity may call this API," that is an IAM question, not a network one.

Because CLI flags and quota values change between plug-in releases, confirm the exact syntax and current limits in IBM Cloud documentation before publishing or automating any of the commands above.