Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support creating operators, accounts and users #129

Open
ripienaar opened this issue Sep 10, 2024 · 1 comment
Open

Support creating operators, accounts and users #129

ripienaar opened this issue Sep 10, 2024 · 1 comment
Labels
proposal Enhancement idea or proposal

Comments

@ripienaar
Copy link
Collaborator

What motivated this proposal?

The new library that allows these things to be done from go

What is the proposed change?

Write new resources matching operators/accounts/users/imports/export etc

Who benefits from this change?

No response

What alternatives have you evaluated?

No response

@ripienaar ripienaar added the proposal Enhancement idea or proposal label Sep 10, 2024
@ripienaar
Copy link
Collaborator Author

ripienaar commented Sep 10, 2024

  • Need to figure out how to allow credentials to be exported here, they could be exported as sensitive data from the resources so other resources can use them to press credentials onto boxes etc. Needs experimentation
  • Generally all of these resources will have public keys and we need to similarly make those available on either a specifically name thing like public_key or just use that as the id the way nsc does, it might be more useful to have a friendly ID and a specifically named public_key data
  • We will start with a single directory hosting the store with nsc data while we figure out how to get the KV backend to have exclusivity locks in it
  • We can only release this when the KV backend is better baked, does not make sense to manage a local directory only, but it's fine to do the dev against that.
  • After account / operator changes we need to push to the network and will need system creds
resource "nats_operator" "DEVCO" { 
  service_url = "https://...." // optional
  tags        = [foo, bar]     // optional
} // should export its public key as data

// this must output the public key as data somehow
// really we need to support some kind of descriptions
// for signing keys but we dont at the moment
resource "nats_operator_sk" "FOO" { 
  operator   = "DEVCO"
  depends_on = [
    nats_operator.DEVCO
  ]
} // should export its public key as data

resource "nats_account" "WEATHER_SERVICE" {
  operator   = "DEVCO"
  
  limits = {                                  // optional
     bearer_tokens = true
     connections   = 1000
     leafnodes     = 100
     payload       = 1024
     subscriptions = 100000
  }
  
  tags                = [foo, bar]             // optional
  expires             = "2028-01-01 00:00:00"  // optional
  
  depends_on = [
    nats_operator.DEVCO
  ]  
} // should export its public key as data

resource "nats_account" "USERS" {
  operator   = "DEVCO"
    
  depends_on = [
    nats_operator.DEVCO
  ]  
} // should export its public key as data


resource "nats_account_export" "WEATHER" {
  operator    = "DEVCO"
  account     = "WEATHER_SERVICE"
  subject     = "weather.v1.>"

  depends_on = [
    nats_operator.DEVCO
    nats_account.USERS
  ]  

  // optional below
  description    = "V1 Weather Service"
  url            = "https://...."
  token-position = 2
  advertise      = true
} // should export its public key as data

resource "nats_user", "BOB" {
 operator    = "DEVCO"
 account     = "USERS"

 depends_on = [
    nats_operator.DEVCO
    nats_account.USERS
  ]  

 // optional below
 signer      = "ID_OF_SIGNINGLEY" // should be looked up by id, see comments below
 tags        = [ tags ]
 
 limits = {
   payload            = 10000
   bearer_tokens      = true
   subscriptions      = 100
 }
 
 publish = {
   allow = [ subjects ]
   deny = [ subjects ] 
 }
 
 subscribe = {
   allow = [ subjects ]
   deny = [ subjects ]
 }
} // should export its public key as data

resource "nats_import" "USERS_WEATHER_SERVICE" {
  operator    = "DEVCO"
  account     = "USERS"
  subject     = "weather.v1.>"
  local       = "services.weather.v1.>"
  
  // how to fetch the public key from the account resource automatically?
  // else this couldnt converge in one run. We could set the public key 
  // as the resource id then it would be like nats_account.WEATHER_SERVICE.id
  // to do the fetch here, that's probably the way to go. Probably this should
  // be how all IDs are generated as we do that for the JWTs anyway
  source      = "WEATHER_SERVICE_PUBLIC_KEY" 

  depends_on = [
    nats_operator.DEVCO
    nats_account.USERS
  ]  

  // optional below
  share       = true
  traceable   = true
  service     = true
} // should export its public key as data

ploubser added a commit to ploubser/terraform-provider-jetstream that referenced this issue Feb 10, 2025
ploubser added a commit to ploubser/terraform-provider-jetstream that referenced this issue Feb 10, 2025
ploubser added a commit to ploubser/terraform-provider-jetstream that referenced this issue Feb 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal Enhancement idea or proposal
Projects
None yet
Development

No branches or pull requests

1 participant