Comments (3)
I think there are two issues regarding sensitive information:
- Output returned from the providers that is stored in tfstate.
- Input from user as a configuration parameter.
The tricky part is that there are cases where without implementing (2), we can't really remove the field. For example, RDS instance has a field to take password. We can copy the content of password
field from tfstate into our connection detail but we can't remove the field from schema because it's used as input to the creation call.
We can possibly either expand the scope of this issue to also generate and process *v1.SecretKeyReference
fields hence remove the sensitive fields completely, or keep the scope as is and don't remove the fields, only make sure that their content in tfstate makes it to the connection detail.
from terrajet.
Good point. Originally, I was thinking the scope of this issue is more around the first one.
But the second could be solved by following a similar solution as we used to mark and generate reference fields, e.g. developer marks the field as sensitive and terrajet adds a secretref field if it is input together with providing function to read it. I don't think we would need a special code generation like reference resolvers though since this case would be simpler.
if field is marked as sensitive & input (i.e. from spec) => generate a SecretKeyRef field and read from the referenced secret in GetParameters.
if field is marked as sensitive & output (i.e. to status) => store in connection details secret in SetObservation (may be also store input secret to connection details).
Considering the possible flow above, I think it makes sense to handle both cases with this ticket.
from terrajet.
generate a SecretKeyRef field and read from the referenced secret in GetParameters.
store in connection details secret in SetObservation (may be also store input secret to connection details).
We'd have to add kube client.Client
argument to GetParameters
function and return a map[string][]byte
from SetObservation
, right?
I think it starts to feel like we're overloading the functions that seem very basic on the outside, i.e. classic getters and setters, with some logic that are normally handled elsewhere in manually written controllers.
I wonder if we can extend Terraformed
interface call those functions in the controller itself. For example:
func (r *RDSInstance) GetConnectionDetails(tfstate map[string]interface{}) (map[string][]byte, error)
func (r *RDSInstance) GetSensitiveParameters(kube client.Client) (map[string]interface{}, error)
What do you think? I don't really love the fact that we'd have to import controller-runtime in apis
packages (we always try to keep what's imported there at minimum so that depending on our apis
is not high-cost) but I couldn't find a nice way of having those functions in clients
or controllers
package while keeping the configuration input in one place, i.e. resource.Configuration
object used in apis/group/*
. And it feels early to have the controller.Configuration
object we had talked about that can be used for non-apis
logic.
from terrajet.
Related Issues (20)
- Reference network interface in VM creation
- How to deploy into existing infrastructure? HOT 2
- Customizable late initialization function for a resource
- Add support for numeric sensitive fields
- PollInterval is not considered by controllers
- main.tf's error message on failed write is incorrect
- Fix security vulnerabilities with hashicorp/go-getter upgrade to v1.6.1 HOT 1
- Fix security vulnerabilities by using Go 1.19 HOT 2
- can't get the correct terraform state file when importing the existed resources HOT 3
- Update documentation and provider-jet-template repo to cover creating a crossplane provider from a CUSTOM Terraform provider
- Allow resource configuration to provide additional state file values
- Terrajet providers take a long time on cluster with many resources HOT 2
- Issue when trying to convert ldap provider
- Need tip with converting ldap provider HOT 12
- Import cycle not allowed HOT 1
- Allow prevent_destroy for provider
- Using "Test":true in TF_REATTACH_PROVIDER cause memory leaks
- Cannot generate provider crds HOT 2
- Support configuring the json tags of a field
- Deprecating Terrajet HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from terrajet.