Jira (PUP-5832) 4.x Sensitive Type - Handle Sensitive data in manifests, logs, catalog, reports and resource types.
Title: Message Title Geoff Nichols updated an issue Puppet / PUP-5832 4.x Sensitive Type - Handle Sensitive data in manifests, logs, catalog, reports and resource types. Change By: Geoff Nichols Epic Status: To Do Done Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5832) 4.x Sensitive Type - Handle Sensitive data in manifests, logs, catalog, reports and resource types.
Title: Message Title Geoff Nichols updated an issue Puppet / PUP-5832 4.x Sensitive Type - Handle Sensitive data in manifests, logs, catalog, reports and resource types. Change By: Geoff Nichols Team/s: Agent Platform Core Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5832) 4.x Sensitive Type - Handle Sensitive data in manifests, logs, catalog, reports and resource types.
Title: Message Title Henrik Lindberg updated an issue Puppet / PUP-5832 4.x Sensitive Type - Handle Sensitive data in manifests, logs, catalog, reports and resource types. Change By: Henrik Lindberg Labels: triaged Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5832) 4.x Sensitive Type - Handle Sensitive data in manifests, logs, catalog, reports and resource types.
Title: Message Title Lindsey Smith updated an issue Puppet / PUP-5832 4.x Sensitive Type - Handle Sensitive data in manifests, logs, catalog, reports and resource types. Change By: Lindsey Smith Team/s: Puppet Developer Experience Agent Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5832) 4.x Sensitive Type - Handle Sensitive data in manifests, logs, catalog, reports and resource types.
Title: Message Title
Eric Thompson updated an issue
Puppet / PUP-5832
4.x Sensitive Type - Handle Sensitive data in manifests, logs, catalog, reports and resource types.
Change By:
Eric Thompson
We currently have no good way of handling sensitive data in a puppet manifest.In PUP-5831 we are adding a binary type. Ticket PUP-3600 is about making that Binary type work as content in an unmodified 3.x PSON/JSON encoded catalog for the File content attribute, but only there. That is not enough for Binary, and certainly no enough for Sensitive data.While other attributes could possibly also be handled as special cases,there is no general handling of binary until we have better serialization. (TBD Ref to ticket). While Binary works for some attributes, it makes it hard to support as the receiving end must know that it may get binary data, and what that binary data represents. Say that it should be a secret Integer - how does the receiver know this and not mistake for say a GIF?To support this, we add a new type; {{Sensitive\[T, chipher]}}, a subtype of {{Binary}} where {{T}} represents the unencrypted value type, and {{chiper}} a chipher reference as in OpenSSL::Chipher. A runtime object maintains both the encrypted and unencrypted value, or just the encrypted value. A {{Sensitive}} value may have to be able to present itself in a surrogate form i certain situations, such a surrogate value must be of the actual data type or usage may break.It is uncertain if the surrogate is of value or if this is a presentation issue as each presentation technology may be happy with just a sequence of asterisks for any data type, a very narrow type (like an Enum would also not be able to have a surrogate if the surrogate is one of the acceptable values. For those reasons a surrogate value should not be included in the design. The Boolean 'value_available' attribute is used to denote if the value attribute is available. This boolean is needed as the value {{T}} may accept {{Undef}}.Thus a sensitive object can be described by he struct type:{code:puppet}Struct[{ value => T, chipher => String, data => Hash[String, Binary], value_available => Boolean }]{code}When creating an instance of {{Sensitive}}, the data may come from a data source where the value is already encrypted. Data sources that supports this, should return an instance of Sensitive instead of the String representation. The data source will have some way of representing the Cipher as well as the encrypted value. When a {{Sensitive}} is created from unencrypted source enough information must be given to enable encryption. The sensitive data can hold multiple encrypted values, one for each recipient. The typical use cases is to allow the master to see the value for the purpose of deriving new values, and for a node, or nodes..The most common case would be to encrypt for a node - the clear data is only readable by the node, but other scenarios may apply (a certificate shared by a group etc.). Information available only to the master, then made available to a node etc. The method that creates a sensitive must therefore be able to handle these various options.In this proposal, the keyname is assumed to uniquely identify a name, and that a node's fqdn is such a suitable key.{code:puppet}Sensitive.new(String $cipher,
Jira (PUP-5832) 4.x Sensitive Type - Handle Sensitive data in manifests, logs, catalog, reports and resource types.
Title: Message Title Henrik Lindberg commented on PUP-5832 Re: 4.x Sensitive Type - Handle Sensitive data in manifests, logs, catalog, reports and resource types. Comments received suggests that the Sensitive type should be called Encrypted as that more clearly signals what it is. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5832) 4.x Sensitive Type - Handle Sensitive data in manifests, logs, catalog, reports and resource types.
Title: Message Title Adam Bottchen updated an issue Puppet / PUP-5832 4.x Sensitive Type - Handle Sensitive data in manifests, logs, catalog, reports and resource types. Change By: Adam Bottchen CS Priority: Critical CS Severity: 4 CS Business Value: 5 CS Frequency: 4 Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5832) 4.x Sensitive Type - Handle Sensitive data in manifests, logs, catalog, reports and resource types.
Title: Message Title Steve Barlow updated an issue Puppet / PUP-5832 4.x Sensitive Type - Handle Sensitive data in manifests, logs, catalog, reports and resource types. Change By: Steve Barlow Scrum Team/s: Language Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5832) 4.x Sensitive Type - Handle Sensitive data in manifests, logs, catalog, reports and resource types.
Title: Message Title Steve Barlow updated an issue Puppet / PUP-5832 4.x Sensitive Type - Handle Sensitive data in manifests, logs, catalog, reports and resource types. Change By: Steve Barlow Sprint: Language Triage Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5832) 4.x Sensitive Type - Handle Sensitive data in manifests, logs, catalog, reports and resource types.
Title: Message Title
Henrik Lindberg updated an issue
Puppet / PUP-5832
4.x Sensitive Type - Handle Sensitive data in manifests, logs, catalog, reports and resource types.
Change By:
Henrik Lindberg
We currently have no good way of handling sensitive data in a puppet manifest.In PUP-5831 we are adding a binary type and in . Ticket PUP-3600 we are is about making a that Binary type work as content in a an unmodified 3.x PSON/JSON encoded catalog for the File content attribute , but only there . That is not enough for Binary, and certainly no enough for Sensitive data. Other While other attributes could possibly also be handled as special cases, but there is no general handling of binary until we have better serialization . (TBD ref Ref to ticket). While Binary works for some attributes, it makes it hard to support as the receiving end must know that it may get binary data, and what that binary data represents. Say that it should be a secret Integer - how does the receiver know this and not mistake for say a GIF ?To support this, we add a new type; {{Sensitive\[T, chipher]}}, a subtype of {{Binary}} where {{T}} represents the unencrypted value type, and {{chiper}} a chipher reference as in OpenSSL::Chipher. A runtime object maintains both the encrypted and unencrypted value, or just the encrypted value. A {{ Sensitive }} value must may have to be able to present itself in a surrogate form i certain situations, such a surrogate value must be of the actual data type or usage may break.It is uncertain if the surrogate is of value or if this is a presentation issue as each presentation technology may be happy with just a sequence of asterisks for any data type, a very narrow type (like an Enum would also not be able to have a surrogate if the surrogate is one of the acceptable values. For those reasons a surrogate value is should not be included in the design . The Boolean ' clear_value value_available ' attribute is used to denote if the value attribute is available. This boolean is needed as the value {{T}} may accept {{Undef}}.Thus a sensitive object can be described by he struct type:{code:puppet}Struct[{ value => T, chipher => String, data => Binary, surrogate =>T, clear_value value_available => Boolean }]{code}When creating an instance of {{Sensitive}}, the data may come from a data source where the value is already encrypted. Data sources that supports this, should return an instance of Sensitive instead of the String representation. The data source will have some way of representing the Cipher as well as the encrypted value. When a {{Sensitive}} is created from unencrypted source enough information must be given to enable encryption.The most common case would be to encrypt for a node - the clear data is only readable by the node, but other scenarios may apply (a certificate shared by a group etc.). Information available only to the master, then made available to a node etc. The method that creates a sensitive must therefore be able to handle these various options.In this proposal, the keyname is assumed to uniquely identify a name, and that a node's fqdn is such a suitable key.{code:puppet}Sensitive.new(String $cipher, String $keyname, T $data){code}Handling data of {{Sensitive}} type in the 3.x catalog is
Jira (PUP-5832) 4.x Sensitive Type - Handle Sensitive data in manifests, logs, catalog, reports and resource types.
Title: Message Title
Henrik Lindberg updated an issue
Puppet / PUP-5832
4.x Sensitive Type - Handle Sensitive data in manifests, logs, catalog, reports and resource types.
Change By:
Henrik Lindberg
We currently have no good way of handling sensitive data in a puppet manifest.In PUP-5831 we are adding a binary type. Ticket PUP-3600 is about making that Binary type work as content in an unmodified 3.x PSON/JSON encoded catalog for the File content attribute, but only there. That is not enough for Binary, and certainly no enough for Sensitive data.While other attributes could possibly also be handled as special cases,there is no general handling of binary until we have better serialization. (TBD Ref to ticket). While Binary works for some attributes, it makes it hard to support as the receiving end must know that it may get binary data, and what that binary data represents. Say that it should be a secret Integer - how does the receiver know this and not mistake for say a GIF?To support this, we add a new type; {{Sensitive\[T, chipher]}}, a subtype of {{Binary}} where {{T}} represents the unencrypted value type, and {{chiper}} a chipher reference as in OpenSSL::Chipher. A runtime object maintains both the encrypted and unencrypted value, or just the encrypted value. A {{Sensitive}} value may have to be able to present itself in a surrogate form i certain situations, such a surrogate value must be of the actual data type or usage may break.It is uncertain if the surrogate is of value or if this is a presentation issue as each presentation technology may be happy with just a sequence of asterisks for any data type, a very narrow type (like an Enum would also not be able to have a surrogate if the surrogate is one of the acceptable values. For those reasons a surrogate value should not be included in the design. The Boolean 'value_available' attribute is used to denote if the value attribute is available. This boolean is needed as the value {{T}} may accept {{Undef}}.Thus a sensitive object can be described by he struct type:{code:puppet}Struct[{ value => T, chipher => String, data => Hash[String, Binary], value_available => Boolean }]{code}When creating an instance of {{Sensitive}}, the data may come from a data source where the value is already encrypted. Data sources that supports this, should return an instance of Sensitive instead of the String representation. The data source will have some way of representing the Cipher as well as the encrypted value. When a {{Sensitive}} is created from unencrypted source enough information must be given to enable encryption. The sensitive data can hold multiple encrypted values, one for each recipient. The typical use cases is to allow the master to see the value for the purpose of deriving new values, and for a node, or nodes..The most common case would be to encrypt for a node - the clear data is only readable by the node, but other scenarios may apply (a certificate shared by a group etc.). Information available only to the master, then made available to a node etc. The method that creates a sensitive must therefore be able to handle these various options.In this proposal, the keyname is assumed to uniquely identify a name, and that a node's fqdn is such a suitable key.{code:puppet}Sensitive.new(String
Jira (PUP-5832) 4.x Sensitive Type - Handle Sensitive data in manifests, logs, catalog, reports and resource types.
Title: Message Title
Henrik Lindberg updated an issue
Puppet / PUP-5832
4.x Sensitive Type - Handle Sensitive data in manifests, logs, catalog, reports and resource types.
Change By:
Henrik Lindberg
We currently have no good way of handling sensitive data in a puppet manifest.In PUP-5831 we are adding a binary type. Ticket PUP-3600 is about making that Binary type work as content in an unmodified 3.x PSON/JSON encoded catalog for the File content attribute, but only there. That is not enough for Binary, and certainly no enough for Sensitive data.While other attributes could possibly also be handled as special cases,there is no general handling of binary until we have better serialization. (TBD Ref to ticket). While Binary works for some attributes, it makes it hard to support as the receiving end must know that it may get binary data, and what that binary data represents. Say that it should be a secret Integer - how does the receiver know this and not mistake for say a GIF?To support this, we add a new type; {{Sensitive\[T, chipher]}}, a subtype of {{Binary}} where {{T}} represents the unencrypted value type, and {{chiper}} a chipher reference as in OpenSSL::Chipher. A runtime object maintains both the encrypted and unencrypted value, or just the encrypted value. A {{Sensitive}} value may have to be able to present itself in a surrogate form i certain situations, such a surrogate value must be of the actual data type or usage may break.It is uncertain if the surrogate is of value or if this is a presentation issue as each presentation technology may be happy with just a sequence of asterisks for any data type, a very narrow type (like an Enum would also not be able to have a surrogate if the surrogate is one of the acceptable values. For those reasons a surrogate value should not be included in the design. The Boolean 'value_available' attribute is used to denote if the value attribute is available. This boolean is needed as the value {{T}} may accept {{Undef}}.Thus a sensitive object can be described by he struct type:{code:puppet}Struct[{ value => T, chipher => String, data => Hash[String, Binary ] , surrogate =>T, value_available => Boolean }]{code}When creating an instance of {{Sensitive}}, the data may come from a data source where the value is already encrypted. Data sources that supports this, should return an instance of Sensitive instead of the String representation. The data source will have some way of representing the Cipher as well as the encrypted value. When a {{Sensitive}} is created from unencrypted source enough information must be given to enable encryption. The sensitive data can hold multiple encrypted values, one for each recipient. The typical use cases is to allow the master to see the value for the purpose of deriving new values, and for a node, or nodes.. The most common case would be to encrypt for a node - the clear data is only readable by the node, but other scenarios may apply (a certificate shared by a group etc.). Information available only to the master, then made available to a node etc. The method that creates a sensitive must therefore be able to handle these various options.In this proposal, the keyname is assumed to uniquely identify a name, and that a node's fqdn is such a suitable
Jira (PUP-5832) 4.x Sensitive Type - Handle Sensitive data in manifests, logs, catalog, reports and resource types.
Title: Message Title Henrik Lindberg updated an issue Puppet / PUP-5832 4.x Sensitive Type - Handle Sensitive data in manifests, logs, catalog, reports and resource types. Change By: Henrik Lindberg Sprint: Language Triage Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5832) 4.x Sensitive Type - Handle Sensitive data in manifests, logs, catalog, reports and resource types.
Title: Message Title Henrik Lindberg updated an issue Puppet / PUP-5832 4.x Sensitive Type - Handle Sensitive data in manifests, logs, catalog, reports and resource types. Change By: Henrik Lindberg Sprint: Language Triage Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5832) 4.x Sensitive Type - Handle Sensitive data in manifests, logs, catalog, reports and resource types.
Title: Message Title Henrik Lindberg updated an issue Puppet / PUP-5832 4.x Sensitive Type - Handle Sensitive data in manifests, logs, catalog, reports and resource types. Change By: Henrik Lindberg Summary: 4.x Sensitive Type - Handle Sensitive data in manifests, logs, catalog, reports and resource types. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
