* test(harness): read agent plan from the scoped store
The store-scoping change moved an agent's plan from the default table
key agent/{name}/plan to its own table (database "agent", table {name},
key "plan"). The plan-delegate harness tests still read the old key and
failed with 'not found'; read through store.Scope(mem, "agent", name)
like the agent does.
* docs: orient agents-first across README, landing, and docs overview
Lead with agents (then services and flows), surface MCP + A2A as the
interop story, and frame agents as services. Landing hero and feature
grid reordered agents-first with an A2A gateway card.
* v6: module path go-micro.dev/v6, TLS secure by default, NewService
Cut v6. Three breaking changes, bundled so the major bump is paid once:
- Module path go-micro.dev/v5 -> go-micro.dev/v6 across all imports + go.mod.
- TLS verification on by default (was off). MICRO_TLS_SECURE removed;
MICRO_TLS_INSECURE=true opts out for self-signed/dev.
- micro.NewService(name, opts...) is the canonical service constructor,
symmetric with NewAgent/NewFlow; micro.New kept as a deprecated alias;
the old name-less NewService(opts...) removed. Generators emit NewService.
Also ports the JWT auth token provider in-module (go-micro.dev/v6/auth/jwt/token
on golang-jwt/jwt/v5), dropping the v5-pinned github.com/micro/plugins/v5/auth/jwt
and the deprecated dgrijalva/jwt-go.
Docs/README/landing updated to v6 and @latest; v5->v6 migration guide added;
CHANGELOG cut as [6.0.0]. Blog posts left at their historical versions.
---------
Co-authored-by: Claude <noreply@anthropic.com>
4.9 KiB
TLS Security Migration Guide
Overview
This document provides guidance for migrating to secure TLS certificate verification in go-micro v5.
Current Status (v5)
Default Behavior: TLS certificate verification is disabled by default (InsecureSkipVerify: true)
Reason: Backward compatibility with existing deployments to avoid breaking production systems during routine upgrades.
Security Risk: The default behavior is vulnerable to man-in-the-middle (MITM) attacks.
Migration Path
Option 1: Enable Secure Mode (RECOMMENDED)
Set the environment variable to enable certificate verification:
export MICRO_TLS_SECURE=true
This enables proper TLS certificate verification while maintaining compatibility with v5.
Option 2: Use SecureConfig Directly
In your code, explicitly use the secure configuration:
import (
"go-micro.dev/v6/broker"
mls "go-micro.dev/v6/util/tls"
)
// Create broker with secure TLS config
b := broker.NewHttpBroker(
broker.TLSConfig(mls.SecureConfig()),
)
Option 3: Provide Custom TLS Configuration
For fine-grained control, provide your own TLS configuration:
import (
"crypto/tls"
"crypto/x509"
"go-micro.dev/v6/broker"
"io/ioutil"
)
// Load CA certificates
caCert, err := ioutil.ReadFile("/path/to/ca-cert.pem")
if err != nil {
log.Fatal(err)
}
caCertPool := x509.NewCertPool()
caCertPool.AppendCertsFromPEM(caCert)
// Create custom TLS config
tlsConfig := &tls.Config{
RootCAs: caCertPool,
MinVersion: tls.VersionTLS12,
}
// Create broker with custom config
b := broker.NewHttpBroker(
broker.TLSConfig(tlsConfig),
)
Production Deployment Strategy
Rolling Upgrade Considerations
The current implementation maintains backward compatibility, allowing safe rolling upgrades:
- Mixed Version Deployments: v5 instances can communicate regardless of TLS security settings
- No Immediate Breaking Changes: Systems continue working with existing behavior
- Gradual Migration: Enable security incrementally across your infrastructure
Recommended Approach
-
Test in Staging:
# In staging environment export MICRO_TLS_SECURE=true -
Deploy with Feature Flag: Use environment-based configuration for gradual rollout
-
Monitor for Issues: Watch for TLS handshake failures or certificate validation errors
-
Full Production Rollout: Once validated, enable across all services
Multi-Host/Multi-Process Considerations
Certificate Trust: When enabling secure mode, ensure:
- All hosts trust the same root CAs
- Self-signed certificates are properly distributed if used
- Certificate validity periods are monitored
- Certificate chains are complete
Service Mesh Alternative: Consider using a service mesh (Istio, Linkerd, etc.) for:
- Automatic mTLS between services
- Certificate management and rotation
- No application code changes required
Future Changes (v6)
In go-micro v6, the default will change to secure by default:
InsecureSkipVerify: false(certificate verification enabled)- Breaking change requiring major version bump
- Migration completed before v6 release avoids disruption
Testing Your Migration
Verify Secure Mode is Active
package main
import (
"fmt"
mls "go-micro.dev/v6/util/tls"
"os"
)
func main() {
os.Setenv("MICRO_TLS_SECURE", "true")
config := mls.Config()
fmt.Printf("InsecureSkipVerify: %v (should be false)\n", config.InsecureSkipVerify)
}
Test Certificate Validation
Create a test service and verify it:
- Accepts valid certificates
- Rejects invalid/self-signed certificates (when not in CA)
- Properly validates certificate chains
Common Issues and Solutions
Issue: "x509: certificate signed by unknown authority"
Cause: The server certificate is not signed by a trusted CA
Solution:
- Add the CA certificate to the trusted root CAs
- Use a properly signed certificate
- For development only: Use
InsecureConfig()explicitly
Issue: "x509: certificate has expired"
Cause: Server certificate has expired
Solution:
- Renew the certificate
- Implement certificate rotation
- Monitor certificate expiry dates
Issue: Services can't communicate after enabling secure mode
Cause: Mixed certificate authorities or missing certificates
Solution:
- Ensure all services use certificates from the same CA
- Distribute CA certificates to all nodes
- Verify certificate SANs match service addresses
Questions?
For issues or questions about TLS security migration, please:
- Open an issue on GitHub
- Check the documentation at https://go-micro.dev/docs/
- Review the security guidelines