terraform-ibm-modules / terraform-ibm-cbr Goto Github PK

CBR has recently been supporting the existing serviceRef with regions which is currently being omitted here -

As per this API List available service reference targets response, now compliance and containers-kubernetes also supports regionality.

Need to Update these serviceRef in location condtion- Total CBR serviceRef NOT supporting locations count: 4 values: ["directlink","globalcatalog-collection","iam-groups","user-management"]

Description

It would be desirable to create 2 different rules for containers-kubernetes as typically different sources will be calling them

One for api-type:cluster, and another one for api-type:management.

Description

Couple of issues with this example:

• The README.md is not fully accurate. It refers to "the module's default variable values" which is not fully accurate. Also it actually demonstrates the submodule https://github.com/terraform-ibm-modules/terraform-ibm-cbr/tree/main/cbr-service-profile
• The CBR topology that is creates, which working, does not really makes sense in a real world scenario.
  • The current topology creates 3 rules (object storage, message hub, kms) and for each of those rules, it adds as a zone a VPC + 2 services (direct link and intrastructure services). I do not think of any real world scenario where direct link would need to be able to access to object storage, message hub or kms in this account.
• I'd suggest aligning the example on the actual flow that exists in landing zone / fscloud topology - eg:
  

New or affected modules

By submitting this issue, you agree to follow our Code of Conduct

Need to add rules for newly added services that is logdna and logdnaat.

• Need to add latest service targets- ['IAM', 'context-based-restrictions', 'globalcatalog-collection', 'logdna', 'logdnaat', 'mqcloud', 'sysdig-monitor', 'sysdig-secure']

Description

Context: CBR APIs / provider (not visible in UI) support creating network zone scoped to a given region.
What: This ticket covers support to add the region as input to the root and cbr-service-profile submodule.

Description

Add some logic to allow consumer to indicate how to skip creation of some rules. Currently the module creates rule for all services in #267

By submitting this issue, you agree to follow our Code of Conduct

Example: https://github.com/terraform-ibm-modules/terraform-ibm-cbr/tree/main/profiles/fscloud - the terra doc in this markdown file is not longer generated.

Note:

Description

Currently missing from

• Now the location feature is also added in the CBR UI while creating zones for each serviceRef.
• As the option to set location for each serviceRef is at more granular level like geo/country/metro locations, how are we going to handle this in a module for each service?
• As we have only one location variable to set for each service and there now might be the case where this location value may not support for every service.
• Below is the list of services and total supporting locations-

Total locations supporting for each ServiceRef:   {
  "apprapp": 12,
  "cloud-object-storage": 32,
  "cloudantnosqldb": 33,
  "codeengine": 25,
  "compliance": 17,
  "containers-kubernetes": 25,
  "databases-for-cassandra": 27,
  "databases-for-elasticsearch": 27,
  "databases-for-enterprisedb": 27,
  "databases-for-etcd": 27,
  "databases-for-mongodb": 27,
  "databases-for-mysql": 27,
  "databases-for-postgresql": 27,
  "databases-for-redis": 27,
  "event-notifications": 16,
  "is": 24,
  "logdna": 27,
  "logdnaat": 27,
  "messagehub": 25,
  "messages-for-rabbitmq": 27,
  "schematics": 12,
  "secrets-manager": 25,
  "server-protect": 24,
  "sysdig-monitor": 25,
  "sysdig-secure": 25,
  "toolchain": 25
}

Affected modules

*terraform-ibm-cbr

Expected behavior

If multiple contexts, resources or operations are provided they should all be added to the rule

Actual behavior

If multiple contexts, resources or operations are provided only the first value is added to the rule

Steps to reproduce (including links and screen captures)

1. Run terraform apply

Anything else

By submitting this issue, you agree to follow our Code of Conduct

Description

More services now support CBR - so the lists here are not longer containing the full list of services supporting CBRs as a rule or as a zone

Add rule for Activity Tracker route -> COS, as logdnaat service now supports CBR.

Description

Feedback from one consumer. Currently flexibility is on the prefix only.

This should be an optional name in the inputs of the module per zone, rule - current support with prefix should remain as well.

By default, this should apply to all endpoint, not only private one.

The current configuration would results in public access not being subject to CBR rule. (update: there is an implicit deny all by default on the endpoints that do not have any zone assigned when another endpoint is assigned a zone. Exception today is with the ICD service but this was confirmed as a bug)

Description

Add this statement in the documentation.

Description

This should not longer be needed to force the implicit deny all on an interface. All Cloud services now have this implicit deny.
This context is also being flagged up by SCC in recent release, creating some noise in audit reports.

Description

2 related aspects in this ticket:

1. Add the ability to scope a rule per region (in addition to the existing instance_id, resourcegroup, tags)
2. When a scope is specified in a rule, get the fscloud module to also create a global 'deny' all rule for the service (using the 1.1.1.1 context). In other words, create 2 rules, a global one and a scoped one. There should be a flag to opt out of this behavior by service (or more exactly by pseudo service to take account of the 2 pseudo services management and cluster for kube)

Context:

• In the current approach, when a rule with a scope is created, the restriction only apply to the instances targeted by this rule. In the absence of a global rule, access is unrestricted for all other instances. This behavior can be see in the fscloud example for kms (scoped to an instance https://github.com/terraform-ibm-modules/terraform-ibm-cbr/blob/main/examples/fscloud/main.tf#L75 )

By submitting this issue, you agree to follow our Code of Conduct

Description

HPCS now supports CBRs, so support should be added.

In the fscloud module, there should be an extra variable kms allowing the consumer to specify whether to add pre wired rules for hpcs, key protect or both. This approach reduces the number of extra boolean variables.

Currently:

"cloud-object-storage" : [{
  endpointType : "direct",
  networkZoneIds : flatten([
    var.allow_vpcs_to_cos ? [local.cbr_zone_vpcs.zone_id] : [],
    var.allow_at_to_cos ? [local.logdnaat_cbr_zone_id] : [],
    var.allow_is_to_cos ? [local.is_cbr_zone_id] : []
  ])

However, AT and IS would access COS through the private endpoint - so there should be an update to have the private endpoint for at and is. direct should only be for VPC.

Description

Needed to enable the iks stack to create things that vpc lb.

Description

Add pre-wired rules to enable ICD databases to talk to KMS. Put it under one single variable allow_icd_to_kms

Description

Based on early consumer inputs on the cbr-service-profile, it would be desirable to create one zone per service, as opposed to grouping multiple services in one zone.

Concretely, taking the existing example at

Update the list of services supporting CBRs as a rule or as a zone.
Newly added services supporting CBR- logdna and logdnaat.

Error in logs:
 Failed to write Flow Log file for the past 24 hours. Dropping flow log for Virtual Server ...

Flow logs writes to COS. Suggest to try adding is-> cos flow in the rule and see if reproducable.

Need to add zone id validation for both existing_serviceref_zone and existing_cbr_zone_vpcs.

Description

• The README.md at https://github.com/terraform-ibm-modules/terraform-ibm-cbr/tree/main/cbr-service-profile should essentially contains the same sections as for the modules at the root of the repo: description, usage section, terradoc generated input/outputs/dependencies . I'd suggest adding the rational there as well on how this submodule differs from the parent one (namely: provides a way to create CBR rules at the account level)
• Reference the submodule from the README.md at top level. It is currently hard to discover. https://github.com/terraform-ibm-modules/terraform-ibm-cbr

Description

Add a submodule (under fscloud directory to follow conventions created from other module) that utilize the submodule https://github.com/terraform-ibm-modules/terraform-ibm-cbr/tree/main/cbr-service-profile to create pre-defined CBR rules needed by the services specified in the FsCloud architecture patterns :
COS -> KMS
Block storage -> KMS
ROKS -> KMS
Activity Tracker route -> COS
VPCs -> container registry
VPCs -> where clusters are deployed -> COS

Description

COS leverage the "direct" endpoint for request coming from VPC as opposed to the private one.

https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-endpoints